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munication line whereby said communication cycle con- 
sists at least of a static segment and/or a dynamic seg- 
ment and respective device, especially node, and re- 



spective method and respective computer program and 
respective computer program product. 
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Introduction 

[0002] This document contains a requirement specification and high-level system description for a dependable au- 
tomotive network. The low-level (implementation) specifications must adhere to this document and should be written 

by the suppliers of the communication controller and physical layer 

Throughoutthedocumentthefollowing structure is followed: at the beginning of each chapter (section) the requirements 
for this topic are defined, afterwards more detailed descriptions are provided. In the document UPPER CASE letters 
are used to denote constants. For a summary of all constants used in the document please refer to Chapter "Constant 
Definitions". 
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Objectives 

[0003] The objectives pursued in the development of the dependable automotive network are the following: 

5 • Support of two communication paradigms, detennlnlstlc (statically defined) communication and dynamic event 
driven communication. 

• Configurable static and dynamic part within one communication cycle. Fully static and fully dynamic configuration 
has to be supported. 

10 

• Flexible extendibility, even after deployment. 

• High data rate and bandwidth efficiency. 

15 • Scalabie fault toierance (i.e., single channel and duai cliannei operation must be supported). 

• Reliable error detection (bus guardian mechanism in the time domain, CRC in the value domain). 

• Support of electrical and optical physical Interfaces. 

20 

• Enable very low system level failure in time ratings 

• Allow use of crystal oscillators and low tolerance ceramic resonators 
25 • Support of active star and bus topologies 

• Low overall system cost 

• Enable re-use of carry over components without embedding knowledge of future platform partitioning. 

30 

Objectives of the static segment: 
[0004] 

35 I Delerminislic communication behavior in the time domain. 

• Global time implemented by a fault tolerant clock synchronization algorithm. 

• Immunity against accepting error-free subsequences of a message as valid messages (i.e. short message rejec- 
40 tion). 

Objectives of the dynamic segment: 

[0005] 

45 

• Event driven dynamic communication possibility. 

• Flexible bandwidth allocation (for different nodes during runtime). 
50 • No interference with the static segment. 

• Support for prioritised bus access. 

• Support of variable length messages with at least 200 data bytes. 
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Global Requirements: 
[0006] 

Support for fault tolerance, but operation without fault tolerance must also be possible, i.e., a single bus (channel) 
connection must be possible for non-fault-tolerant nodes. 

The communication network has to support a system architecture, where no single fault may lead to a functional 
degradation. 

Protection against faults in accordance with a well-defined fault hypotheses. 

Protect against up to and including five random bit errors per frame. 

The communication protocol should be independent as far as possible from the topology. 

For highly dependable and fault-tolerant applications an independent bus guardian to prevent the monopolisation 
of the communication medium by a communication controller is required. 

Errors in hardware and configuration data have to be detected during initialisation and operation by error detection 
mechanisms (EDMs). In case a critical error is detected the controller and transceiver must not be allowed to enter 
normal operation or immediately abort normal operation and report an error to the host. 

Support of serviceability of system- and component-level faults. 

The bit encoding technique must not introduce data dependent changes in the length of the resulting bit stream, 
e.g., bit stuffing is not allowed. 

Automotive qualification of the communication controller, bus guardian, and the physical layer is required. 
Configuration data must be readable/wrlteable by the host. It must be possible to prohibit writing during run-time. 
Support of comprehensive self test at system communication startup. 

Support of timely and highly reliable component re-integration and system-level startup. 
Support of master-less system startup and shutdown. 

Support of traceability of system- and component-level faults to identify root causes of failures. 
Support of synchronized system shutdown without error indications. 

Support of synchronous distributed application startup and shutdown with acceptable timing and fault tolerance 
characteristics, 

Support of node and network moding with high security against critical inadvertant mode changes. 

Logical line compatibility to the byteflight protocol (See byteflight specification at http://www.byteflight,com), when 
using an optical physical layer must be possible. 

Basic Concepts 

[0007] The communication protocol for the dependable automotive network described in this document has the fol- 
lowing properties: 

• Synchronous and asynchronous frame transfer. 

• l\^ulti-master clock synchronization. 
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• Guaranteed frame latency times and jitter during synciironous transfer. 

• Prioritization of frames during asynchronous transfer. 
5 • Error detection and signaling. 

• Error containment on the physical layer through an independent bus guardian device. 

• Scalable fault tolerance, e.g., one controller, oneAwo channels, one bus guardian for each channel. 

10 

[0008] The layered architecture of the FlexRay protocol is shown in Figure 1 . 

• The Physical Layer defines how signals are actually transmitted. One task of the Physical Layer is to detect errors 
of the communication controller in the time domain. This is done by the so-called Bus Guardian (Chapter 0). 

15 

• The Transfer Layer represents the kernel of the protocol. It presents frames received to the presentation layer and 
accepts frames to be transmitted from the presentation layer. The transfer layer is responsible for timing, synchro- 
nization, message framing, error detection and signaling, and fault confinement (Chapter 0). 

20 • The Presentation Layer is concerned with frame filtering and masking, frame status handling and contains the 
communication controller host interface (Chapter 0). 

• The Application Layer is not part of this specification. 

25 Node (ECU) Archltectu re 

[0009] Figure 2 shows the architecture of a node (ECU). Every node consists of the five sub-components host, 
communication controller, bus guardian, bus driver, and power supply. This specification describes the requirements 
for the communication controller, the bus guardian, the bus driver and the interfaces to the host and the power supply. 
30 Two implementations for the communication controller are possible, one configuration of a communication controller 
that sends and receives on two redundant physical channels, and a second configuration which is solely connected 
to one physical channel. 

Topology 

35 

[0010] Figure 3 shows the possibie topology configuration of the communication network. A node can either be 
connected to both channels 1 and 2 (node A, C, and E) or only channel 1 (node B) or only channel 2 (node D), A 
configuration, where all nodes are connected by 1 channel only is also possible. 

40 Frame Transfer 

[0011] Communication is done in a communication cycle consisting of a static and a dynamic segment, where each 
of the segments may be empty. The first frame ID in a system with a static segment is ID number 1 (see Figure 4). In 
a pure dynamic system with the SOC symbol (see Figure 5) . The sending slots are represented through the ID numbers 

45 that are the same on both channeis. 

The sending slots are used deterministicaily (in a pre-defined TDMA strategy) in the static segment. In the dynamic 
segment there can be differences in the phase on the two channels (see Figure 4). Nodes that are connected to both 
channels send their frames in the static segment simultaneously on both channels. Two nodes, that are connected to 
one channel only, but not the same channel, may share a slot in the static segment. 

50 To guarantee the consistency of the clock synchronization only nodes can participate that send frames, which are 
received by all other nodes (e.g., node A, Cand E in Figures). All nodes execute the clock synchronization algorithm, 
but only the frames of the static segment are considered. It is possible to send different data in the same sending slot 
on different channels. 

55 
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Constraints 
[0012] 

5 • The communication controiler must aliow to interface to an optical or an electrical physical layer. 

• The communication controller must support a net data rate of at least 5 Mbit/s real application data transferred per 
seconds under the constraints of frame overhead (including CRC) and protocol timing overhead (IFG) in static 
communication mode. 

10 

• It must be possible to connect 2 up to CONTROLLER_MAX controllers to one communication channel. 

• The maximum number of slots in the static segment is set to STATIC_SLOTS_MAX. 

15 t The power supply for the bus driver (including the bus guardian) and the communication controller must meet 
automotive requirements. 

Comment 

20 [0013] Considering the FlexRay protocol as described in the previous sections the communication scheme of net- 
worked FlexRay nodes can be briefly characterized as follows: 

• each node must be able to mal<e use of the distributed clock 

25 • each node must send frames inside a predefined static slot 

or/and 

inside the dynamic segment (collision free access) 
the transmission of frames must be subdivided into 3 phases 

30 

1 ^ a bus guardian must enable the access to the bus 
2"'^ it must be signaled that a frame should be transmitted 
3"^ the transmission of the frame itself 

35 Protocol Description 

[001 4] Throughout the document the following notation is used: 

Reg : Requirements. 
40 Comment: Contains additional descriptions and explanations. 

General Requirements 

[0015] 

45 

• Reg: The communication protocol shall be independent from the data rate. 
Comment: 

It shall be possible to implement low end controllers e.g., 500 KbiVs and high end controllers beyond 100 MbiVs. 

50 • Reg : The first communication controller must support a net data rate of at least 5 Mbit/s. 
Comment: 

Net data rate: Real application data transferred per secorids under the constraints of frame overhead (Including 
CRC) and protocol timing overhead (IFG) In static communication mode. 

55 * Reg : A CRC code with a Hamming Distance of at least 6 must be used. 

• Reg : The communication controller shall be able to operate in a current byteflight environment, i.e., the two protocoi 
controllers have to support the same physical interface and the same representation at the logical line level. The 
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byteflight compatibility is required for tiie optical physical layer only. 

Comment: 

Compatibility of the interfaces between host CPU and the protocol controller (CHI) is not required. The electrical 
physical layer does not need to support byteflight compatibility. The byteflight specification can be downloaded 
5 from the following web address: www.byteflight.com. 

Frame Transfer 

[0016] Data transfer in FlexRay is done in cycles, called communication cycles. 

10 

• Reg : The communication cycle consists of a static and a dynamic segment as shown in Figure 4. Each of the 
segments may be empty, that means there are three possible configurations of the communication cycle (pure 
static, mixed static and dynamic (a mixed system consists of at ieast two static slots) and pure dynamic). 

In a pure dynamic system the communication cycle starts with an SOC symbol. There are two different SOC 
IS symbols (alarm condition, normal condition). The sending siots are represented through the identifiers that are the 

same on both channels (see Figure 4). 

The sending slots are used deterministically (in a pre-defined TDIVIA strategy) in the static segment. In the dynamic 
segment there can be differences in the phase on the two channels (see Figure 4). Nodes that are connected to 
both channels send their frames in the static segment simultaneously on both channels. A node that is connected 
20 to only one channel may share an identifier with another node that is only connected to the other channel. 

The current communication cycle is detemnined by a cycle counter that is consistently incremented in every cycle 
(see Figure 7). 

• Reg: The length of the communication cycle has to be stored in the configuration data. 
25 Fit Criteria: 

The maximum cycle length is defined by CYCLE_LENGTH_MAX. 

• Reg : A checl< mechanism has to be designed that ensures that no frame transmission is started within a certain 
interval so called forbidden region before the end of the communication cycle, to ensure that the beginning of the 

30 static segment in the next communication cycle is not disturbed. 

• Reg : Multiplexing of sending slots of one controller must be supported in such a way, that the contents of frames 
can be multiplexed for a certain sending slot in different communication cycles. 

Comment: 

35 So a communication matrix with nearly any possible communication patterns (periods of certain frames) based on 

the principle of communication cycles can be built up. 

Static Segment 

40 [0017] 

• Reg : If the static segment of the communication cycle is not empty it consists of STATIC_SLOTS_MIN < 
NUMBER_OF_SLOTS < STATIC_SLOTS_MAX. 

45 » Reg : The static segment is subdivided into a sequence of time slots. In each of these static slots only one controller 

may send one frame on each channel. 
Comment: 

In the static segment of the communication cycle a TDMA media access strategy is used. 

50 • Reg : There is one configuration parameter for the slot length (slotjength) in the static segment, that defines this 
value.. The length of the slots is configurable off-line but fixed during runtime. 

Dynamic Segment 

55 [0018] 

• Reg : In a pure dynamic system the communication cycle starts with the SOC symbol. 
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30 



45 



• Reg : The dynamic segment of the communication cycle consists of zero or more dynamic identifiers (siots) within 

the communication cycie. 

• Reg : Bus access in the dynamic segment is done via static frame priorities according to the bytefiight specification. 
Comment: 

The bytefiight specification can be downloaded from the following web address: www.byteflight.com. 

• Reg : in the dynamic segment the media access strategy is based on wait times (mini-slotting scheme) and the 
priority of identifiers. Controllers transmitting frames with higher priority identifiers send before controllers trans- 
mitting lower priority frames. 

• Reg : The frame length in the dynamic segment is variable during runtime. 

• Reg : In pure dynamic mode an external triggered SOC generation and with it the start of the communication cycie 
has to be supported. The timing behavior of the external trigger has to be monitored by the communication con- 
troller. 

Frame Format FlexRay 

[0019] 

• Reg: Two frame formats as specified below must be supported. 

Comment: 

The mixture of the two frame formats need not be supported, i.e., all nodes connected to a FlexRay communication 
system can be configured using only the FlexRay format or the bytefiight format. 

FlexRay Frame Format 

[0020] 

• Reg : It must be possible to use the FlexRay format in a pure static, in a combined static and dynamic, and in a 
pure dynamic configuration. 

• Reg : The first section of the data field in a frame must be configurable as a message ID field. This data field must 

be filterable by Ihe receiver. 

[0021] Figure 7 shows the FlexRay frame format: 

Res: Reserved bits, 4 bit, for future protocol extensions. 

ID: Identifier, 12 bit, value domain: (1.,q ... 4095.,q), defines the slot position in the static segment and 

defines the priority in the dynamic segment, see Figure 4. A lower identifier determines a higher priority. 
The identifier of a frame must be unique within a cluster. Each controller can have one or more iden- 
tifiers (in the static and the dynamic segment). 



SYNC: Synchronization field, 1 bit, indicates that the slot is used for clock synchronization. 

DLC: Data length code field, 7 bit, DLC * 2 = number of data bytes (Oig, 2^^ 246io). 

50 H-CRC; 9 Bit Cyclic Redundancy Check - Sequence. The H-CRC is calculated over the SYNC- and DLC-field. 

NF: Null frame indication field, 1 bit, indicates that the corresponding data buffer is not updated by the host 
before sending. 

55 CYCO: Cycle Counter, 6 bit, the cycle counter is increased simultaneously in all nodes by the controller at the 

start of each new communication cycle. 

Message ID: The Message ID field is configurable to be used as the message identifier or as the first two data bytes. 
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DO ... D246: Data bytes, 0-246 bytes. 

CRC: 24 Bit Cyclic Redundancy Checl< - Sequence. The CRC is calculated over the complete frame. 

5 byteflight Frame Format 
[0022] 

• Reg : The byteflight frame format must be supported for pure dynamic configurations. 

10 

[0023] Figure 8 shows the byteflight Irame format. 



ID; Identifier, 8 bit, value domain: (1 10 ... 255^o)i defines the priority In the dynamic segment, see Figure . 

A lower Identifier determines a higher priority The Identifier of a frame must be unique within a duster. 
15 Each controller can have one or more identifiers. 

Res: Reserved bits, 4 bits, for future protocol extensions. 

LEN; Length field, 4 bit, LEN = number of data bytes (0,o ... 12-|o), a value higher than 12 Is handled as LEN=12. 

DO ... D1 1 : Data bytes, 0-1 2 Bytes 

CRC: 15 Bit Cyclic Redundancy Checic - Sequence (x^s + x'"'* + xi° + + + + + 1 ). 

20 FCB: Fill completion bit: an additional bit is added to the 15 bit CRC to fill the complete word. The bit is set to 

"0" as LSB. 



Frame Scheduling - Multiplexing of Sending Slots 
25 [0024] 

• Req : The cycle counter can be used to distinguish between different frame contents. 
Comment: 

For a sending siot different send and receive buffers can be defined in different cycies (slot multiplexing). 
30 Comment: 

The cycle counter can be used as a logical &ctension to the identifier (in the case of multiplexing). 
Frame and Bit Coding 
35 [0025] 

• Req : The coding algorithm in the communication controller has to be robust against: 

glitches 

40 

Optical Physical Layer 
[0026] 

45 » Req : The controller must support at least the byteflight optical bit encoding. 

Comment: 

In byteflight, frames on the communication media are composed of Individual bytes consisting of a start bit, eight 

data bits and a stop bit 

In addition, transmission of each frame begins with a start sequence consisting of 6 logical "O'blts. This is liiustrated 

50 by the diagram in Figure 9. 

[0027] Figure 9 shows the transmission of the start sequence. 

Due to certain effects in the optical transmission, it is possible for the start sequence to be become shorter or 
longer during optical transmission. This is why the receiver accepts start sequences in the region of 1-9 logical "0" bits. 
55 This is illustrated by the following diagram in Figure 10. 

[0028] Figure 1 0 shows the reception of the start sequence. 
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Electrical Physical Layer 
[0029] 

5 • Reg : Frames on the communication media for the electrical physical layer are composed as shown in Figure 11 . 
The frame end sequence may be empty. 

[0030] Figure 11 shows the frame fonnat for electrical transmission. 

10 * Reg : A suitable bit coding schema has to be selected, in accordance to bandwidth efficiency and ElVIC require- 
ments. 

Frame Timing 

15 [0031] 

• Reg : Frame timing of different communication controller Implementations must be interoperable. 
Frame Timing for Static Segment 

20 

[0032] 

• Reg : The reception start window shall be defined In relation to the precision. I.e., the start window must be greater 

than the precision. 
25 Comment: 

The actual value for the reception start window must be defined in the implementation specification. 

• Reg : In the static segment accurate timing requirements have to be ensured for correct frame reception. Frames 
may only start within the reception start window. 

30 Comment: 

The length of the frame determines the frame duration. Correct reception is given if the respective frame does not 
violate the temporal borders given by the access scheme. The judgement of temporal correctness is based on a 

rigid timing scheme. 

35 » Reg: The time difference between the predicted start StartNom and the observed start of the frame (SOP) is used 
by the clock synchronization algorithm. 

• Reg : The length of the IFG has to be minimized. In order to optimize the net communication rate. 
40 Frame Timing for Dynamic Segment 

[0033] 

• Reg : The frame timing in the dynamic segment must be defined due to the fcyfeffigfhf specification. 

45 

Start-up 
Requirements 
50 [0034] 

• Reg : For each configuration (Pure Static Systems, Pure Dynamic and IVIixed System) the start-up of the commu- 
nication networic has to be possible as soon as two nodes are able to communicate. 

55 • Reg : The integration of controllers that are powered on later must not disturia the start-up procedure of the other 
nodes. 

• Reg : The start-up and re-lntegratlon of controllers shall not disturb the normal operation of the networl<. 
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• Reg : The worst-case start-up time under the fault conditions given above has to be provided and guaranteed by 
the supplier of the communication controiler. The communication networl< must be operational after 1 00 ms. 
Comment: 

The applies tion designer has to consider the start-up time during the determination of the configuration parameters. 
Typical automotive applications require a worst case startup time of 100ms. For system configurations with ex- 
tremely long communication cycles longer startup times are acceptable. 

• Reg : During start-up a communication controller sets the cycle counter according to the value in the received 
frame. The cycle time is derived from the frame ID and set accordingly. 

• Reg : The startup must work without reliance on collision detection. 
Comment: 

Collisions can occur on the bus during start-up and in the case of faults. In star topologies collision detection Is 
not always feasible. 

Principle of Operation - Protocoi lUodes 

Pure Static System and iVIixed System 

[0035] 

• Reg : The start-up has to worl< as a distributed algorithm. 

• Reg : Only controllers that participate in clock synchronization (sync bit set) are allowed to start up the system. 
Comment: 

In a dual channel system only controllers connected to both channels are allowed to execute the start-up in a 
heterogeneous topology (mixing controllers with single channel and controllers with dual channel). 
Controllers connected to only one channel are not allowed to start-up the bus because they may corrupt the traffic 
of this channel in case of an incoming-linli failure by sending frames after the listen-timeout (listen_timeout). 

• Reg : The start-up of the communication networic, the integration of nodes powered on later and the re-integration 
of failed nodes must be fault-tolerant against: 

• the temporary/permanent failure of one or more communication controllers (down to one controller sending 
in the sialic segment for mixed or pure static configurations), 

• the temporary/permanent failure of one or more communication channel(s) in a redundant configuration, and 

• the loss of one or more frames. 

Pure Dynamic System 
[0036] 

• Reg : A single master sends the SOC symbol. The master shall be defined at design time. 
Shutdown 

[0037] 

• Reg : The co-ordinated shutdown of the FiexRay cluster, Including ail nodes and ail stars initiated by the application 
must be possible. The interference with the wake-up mechanism must be handled. 

• Reg: The communication system has to support a synchronized system shutdown without error indications. 
Cioci< Synchronization 

[0038] Comment: 

The proper synchronization of the individual clocks of the communication controllers is a pre-requisite for the TDMA 
communication scheme. 
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This chapter contains the description of the FlexRay clock synchronization mechanism (based on the Fault-Tolerant 

Midpoint algorithm). 

Pure dynamic system 

5 

[0039] 

• Reg : In a pure dynamic operation the clocl< synchronization is perfonned by a master (SOC). 
10 Pure Static and Mixed System 

[0040] 

• Reg : The globai time is a vector of two values. Global time = < cycle_counter, cycle_time >. 

15 

• Reg : The cycle time is a counter Incremented in units of macroticl<s. The cycle time is reset to 0 at the beginning 
of each communication cycle. 

• Reg : The macroticl< defines the resolution of the global time within one cluster. A resolution of 1 \is must be achiev- 
es able in realistic configurations. 

• Reg : The macrotick shall be independent of oscillator frequency. 
Comment: 

In the implementation each (local) macrotick is an integer multiple of the (local) clocktick, i.e. depends on the 
25 oscillator frequency, but the factors of two different macroticks can be different, so over a cycle. Independence can 

be achieved. 

• Reg : The microtick defines the accuracy of the clock difference measurement. A resolution of <=50 ns Is reguired 
for the microtick. 

30 Comment: 

Typical automotive appllcattons require a resolution of 50 ns. For system configurations with low bandwidth, higher 
values are acceptable. 

• Reg : The clock synchronization mechanism must be able to keep all fault-free controllers within the precision. A 
35 clock synchronizalion precision within the different controllers of better than 1 microsecond is required. 

Comment: 

Typical automotive applications require a precision of 1 microsecond. For system configurations with lower preci- 
sion requirements, greater values are acceptable. 

40 • Reg : The absolute value of the global time must be the same at every controller, within the limits defined by the 
precision. During start-up the first sending node detennlnes the value of the global time. 

• Reg : The fault tolerance of the clock synchronization mechanism must be scalable with the number of controllers. 
The level of fault tolerance depends on the number of actual nodes in the system (3k+1 to tolerate k asymmetric 

45 faults). . In a reduced fault-tolerant configuration of less than four controllers (e.g., 2 or 3, in a degraded mode of 

operation) the synchronization must be possible. For4to 6 controllers the clock synchronization mechanism must 
be fault-tolerant against 1 (asymmetric) fault. For 7 or more controllers the clock synchronization mechanism must 
be fault-tolerant against 2 (asymmetric) faults, 

50 • Reg : The clock synchronization mechanism must prevent the formation of cliques with different notions of time 
within the network. 

• Reg : The clock synchronization mechanism must be able to operate with oscillators that have automotive quality. 
In particular the clock synchronization mechanism must be able to deal with the physical phenomena (drift, dete- 

55 rioratlon) that can occur during an automobile lifetime. 

• Reg : A subset of controllers must be configured to send sync-frames (a frame with a set SYNC bit). In a dual 
channel system only controllers connected to both channels may belong to this subset. 
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• Reg : Only one static sending slot of each controller is allowed to contribute to the clock synchronization mechanism, 
i.e., a controller may send at most one sync-frame per communication cycle. 

• Reg : Only correctly received sync-frames are used for clock synchronization. 

5 

• Reg : Every node has to use all available sync-frames for clock synchronization. 

• Reg : The clocksynohronization and the implementation of the clock synchronization shall be as resilient as possible 
against design violations resulting from environment or possible misuse. 

10 

Principle of Operation 
Obtaining the time values 
15 [0041] 

• Reg : in the static segment every node measures the time difference between the actual receive time and the 
expected receive time for the sync-frames with a resolution of a microtick. 

20 • Reg : This time difference measurement is done for all channels. 

• Reg : An SOF-window is placed around the expected receive time of an SOF. The length of the receive-window is 
egual to the length of the SOF-window. 

25 • Reg : Time values are obtained for correct frames only. 
Comment: 

Note that one of the reasons why a frame is considered Incorrect is reception outside the receive window. The 
stringent application of the receive-window mechanism ensures that synchronization errors of nodes are detect- 
able. 

30 

Measurement method 
[0042] 

35 » Reg : The measurement of the clock deviations is done through measuring the differences between the expected 
arrival time and the actual arrival time . The expected arrival time of a frame is defined by the internal view of the 
cycle time. 

Synchronization algorithm 

40 

[0043] 

• Reg : The synchronization algorithm uses a fault-tolerant midpoint algorithm (FTM) that operates with an arbitrary 
number of controllers. 

45 Comment, Description of the FTtVi: 

The measured values are sorted and the k largest and smallest values are discarded, /c is adapted dynamically 
so that at least 2 measured values are remaining. 

The largest and the smallest of the remaining values are selected for the calculation of the midpoint value, i.e., 
average of those two values. The resulting value in a node describes the deviation of the own clock from the global 
50 time base and serves as a correction term. 

• Reg : The resulting correction tenn(s) shall be used for error detection of the communication controller. If the cor- 
rection term cannot be applied, an error has to be signaled to the host. 

55 • Reg: The clock correction tenn(s) calculated In the previous step shall be applied to the local clock. 

• Reg : If egual or more than half of the frames are received outside the reception start window a synchronization 
error is indicated to the host. The synchronization error is a fatal error the controller has to reintegrate. 
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Comment: 

This mechanism prevents the formation of 
cliques. 

5 External Synchronization 
[0044] 

• Reg : External synchronization must be supported. 
10 Comment: 

External synchronization is necessary for the synchronization of a FlexRay network to an external time reference, 
e.g., a GPS receiver or a DCF77 receiver, or to synchronize several FlexRay networks. 

• Reg : Each controller can add an additional external clock correction term(s) to the calculated clocl< correction tenn 

15 (s). 

• Reg : The resulting clocl< correction term(s) shall not be greater than the maximum allowed correction term{s) or 
smaller than the minimum allowed term(s). The communication controller shall limit the applied correction temn(s) 
to allowed values. 

20 

• Reg : The host shall be able to read the current (local) correction term(s) (current clock value) and set the external 
correction term(s). 

• Reg: A hardware input signal at the communication controiier for external synchronization is reguired. 

25 

• Reg : The hardware input signal shall be connected to the internal soft-reset of the controller. It shall be possible 
to release the controller from soft reset at a specific time by the host. 

Support of Application Agreement Protocois 

30 

[0045] 

• Reg : The protocol has to support the realization of application agreement protocols. This reguires multiple sending 
slots to achieve agreement within one communication cycle. . 

35 

Support of Networit iVIanagement 
[0046] 

40 * Reg : Support of synchronous distributed application startup and shutdown with acceptable timing and fault toler- 
ance characteristics. 

• Reg : Support of node and network modes with high security against critical Inadvertant mode changes. 
45 IHardware Specification 

[0047] This chapter contains a description of hardware-related requirements for a FlexRay system. 
General Requirements 

50 

[0048] Regarding the communication hardware, a distributed system of FlexRay nodes must offer some properties 
when being designed by using active stars and passive busses: 

• Reg : One and two channel solutions have to be supported. 

55 

• Reg : An electrical and optical physical layer must be supported. 

• Reg : Communication via redundant physical links is optional. The communication system must support both com- 
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munication via redundant and non-redundant physical links. A mix of redundant and non-redundant physical linlcs 

must be supported. 

• Reg : When using active stars several 1 :1 links must be used. 

5 

• Reg : Wake-up of nodes and stars via the communication system must be supported. Signaling on one channel is 
sufficient for wake-up. 

• Req : A baud-rate from 500 Kbit/s up to 10 MbWJs must be supported. 

10 

• Req : A power mode management must be supported. 
Topology 

15 [0049] 

• Reg : The protocol has to be independent from the topology as far as possible. Mixed and homogeneous system 
topologies must be supported. 

20 • Reg : A FlexRay network using a passive bus must be possible. 

• Req : A FlexRay network using a passive star must be possible. 

• Reg: A FlexRay network using a active star must be possible. 

25 

• Reg : Support for different topologies/physical layers on different channels is desirable. 

• Req : Support for different physical layers on one channel is desirable. 

30 [0050] Figure 12 shows an example of a topology of a FlexRay network using active stars. 
[0051] Figure 13 shows an example of a topology of a FlexRay network using a passive bus. 

• Req : A distributed system of FlexRay nodes can be designed by combining the active star and the passive bus 
approach. Several nodes may be connected to a branch. 

35 

[0052] Figure 1 4 shows an example of a topology of a FlexRay network using an active star combined with a passive 

bus. 

Each node must adhere to the following requirements: 

40 * Req : Within a node 1 or 2 bus drivers must be connected to a single communication controller 

[0053] Figure 15 shows a block chart of a FlexRay node. 

Each active star must adhere to the following requirements: 

45 • Req : No communication controller is required to perform the star functionality. 

• Reg : No host is required to perform the star functionality. 

Comment: 

An implementation may integrate tiie star within an ECU. 

50 

• Req: A branch of an active star has to be de-activated if a faulty communication signal Is detected: 

1) pemnanent "0" on the bus 
or 

55 2) permanent "1 " on the bus 

or 

3) permanent noise on the bus 
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• Reg : A de-activated branch may not influence the communication of the active moduies (fali silent). 

• Reg : A de-activated branch has to be re-activated if the failure condition which leads to a faulty communication 

signal is no longer available. 

[0Q54] Figure 1 6 shows a block chart of an electrical active star. 

Automotive Constraints 

[0055] 

• Reg : FlexRay devices must meet automotive temperature requirements. 

Comment: 

General temperature requirements include a range of -40 to +125 degrees Celsius. Special applications may re- 
quire liigher temperatures, e.g., near braking actuators. 

• Reg : Each product has to be optimised to meet the automotive and legal EMC requirements (for Strongest severity 
level see DaimierChrysier: A0000007199, BIVIW: GS 95002). External filters may not be required. 
Comment: 

Listed severity levels as named will not be achievable v/hen usirig a passive bus. 

• Reg : The power consumption during the normal operating mode and the low power mode has to be minimised. 

Comment: 

Typical values are given In the following table: 



Table 1 : 



Typical current consumption. 


Function 


IVIin. 


Typ. 


Max 


Unit 


Remaric 


Quiescent current (from the permanent 
power) of the bus driver 




10 




txA 


Thebus drivermonitors wake-up events, 
the voltage regulator is switched off 


Current for the bus driver and the 
communication controller 




10 




mA 


bus free - no actual communication 


Current for the bus driver and the 
communication controller 




50 




mA 


bus busy - communication active 



• Reg : The voltage supply for the communication controller should be the same as for commercially available ECUs. 
Comment: 

Today most ECUs support 5 V. For optimisations e.g., 3 V are allowed. 



• Reg : Ail inputs and outputs of the bus driver and the communication controller which are directly coupled to the 

wire harness have to fit the known electric requirements (Schaffner pulses (high ESD), power voltage up to 60 V, 
see EMC Target Specifications). Support of future high supply voltages (36/42 V instead of 1 2 V) must be supported. 

Architecture - Power iUlodes 

[0056] The chapter summarises the requirements on the communication controller and the bus driver to run an ECU 
in several modes. 

• Reg : The power modes of the ECU must be sensitive to control signals from the host and wake-up signals from 
the transmission media, from the ECU internally (e.g., from the host) and optionally from the ECU externally (e. 

g., by a switch). 

• Reg : At least 3 power modes must be distinguished for communication controllers and bus drivers and stars: 

Normal (voltage regulator(s) active, communication possible) 
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Standby (voltage regulator(s) active, communication not possible) 
Sleep (voltage regulator(s) not active, communication not possible) 



Table 2: 



Power modes. 


Power Mode of the 
Node 


Communication 


Power 
Suppiy 


Normal 


available 


available 


Standby 


not available 


available 


Sleep 


not available 


not available 



• Reg : The power modes of the active star must be controlled by the bus drivers automaticaliy. It is not desire- 
able that a dedicated 'wake-up' and 'shut-down' command is send to the star or additional wiring is required. 

Communication Controiier 

[0057] 

20 

• Reg : A communication controller must include an interface (Has to be confirmed among the suppliers, the most 

commonly used [iCs have to be connectable.) to connect a host. 

• Reg : Parts of the behaviour visible to the host, e.g., application control, configuration, message area, communi- 
cation controller status, interrupts, etc. have to be confinned among the suppliers and specified. 

• Reg : The time base of the redundant channels must be the same within each node (e.g. , by a single state machine) . 

• Reg : The functionality of the communication controller must be independent of the existence of a bus guardian. 

30 

• Reg : For a stand-alone controller the pin-out must be completely specified and documented. 
States and Operating Modes 

3^ [0058] 

• Reg : Power-on and NOT (power-on) must be distinguished at least. 

• Reg : The controller has to be passive outside the mode power-on. 

40 

• Reg : The controller has to be resetable externally. 

• Reg : The controller has to support at least one low-power mode. 

'^^ • Reg : The controller modes have to be defined in accordance with the bus driver modes. 
Logicai Line Operation 
[0059] 

50 

• Reg : At least the following information has to be distinguished: 

• bus busy: data or SOC symbol are transmitted. 

• bus Idle. 

55 

• Reg : The encoding/decoding method has to allow both optical and electrical communication networks. At least 

one method has to be supported; 
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• NRZ (see byteflight specification). 

• Reg : Bit sampling must be robust against disturbances typicaliy inside vehicles e.g., signal delay, edge jitter, baud- 
rate jitter 

5 

• Reg : Bit sampling must be able to deal with e.g., temperature variations or tolerances of electrical and physical 
parameters. 

Optical Driver 

10 

[0060] 

• Reg : See the bytefiight specification. 
15 Electrical Bus Driver 

[0061] 

• Reg : For a bus driver the pin-out must be completely specified and documented. 

20 

• Reg : For redundant configurations an implementation has to be chosen which minimizes the probability of common 
mode failures of both bus drivers each redundant communication is disturbed). 

Comment: 

Two bus drivers to support redundant communication by a single communication controller may possibly not be 
25 implemented on a single die. 

Two bus drivers to support redundant communication by a single communication controller can be integrated In 
one package, if any common mode failure can be excluded. 

• Reg : The bus driver must provide status information and diagnostics infonnation which can be read by any ^- 
30 controller optionally. 

• Reg : The bus driver must be protected against electrical over-voltage and short-circuits. 
Voltage lUlonitoring 

35 

[0062] 

• Reg : The bus driver must monitor the battery voltage and has to provide status information. 

40 * Reg : The bus driver must detect an interrupted connection to the battery and has to provide status information. 
States and Operating iVIodes 

[0063] The bus driver has to support several states or operating modes: 

45 

• Reg : Power-on and NOT(power-on) must be distinguished 

permanent power 
50 regulator voltage 

• Reg : The bus driver has to support at least two low-power modes. 

• Reg : The bus driver has to be able to signal an internal power down mode to an external voltage regulator. 

55 

• Reg : the bus driver has to support a "shutdown mode" 

this mode has to be reached by secured mechanisms on demand of the host 
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this mode must be left only by a power down 

the bus driver has to be passive and has to signal to the voltage regulator to switch off. 

• Reg : The bus-levels have to be chosen by the bus driver automatically to support any net-wide power down modes. 

5 

Bus Guardian 
[0064] 

10 * Reg : The failure of a communication controller In the time domain, e.g., a communication controller sends In a 
time slot when it is not allowed to send, must be prevented by a bus guardian. The probability for common mode 
failures in the time domain affecting both, the communication controller and the bus guardian must be sufficiently 

low. 

15 t Reg : The bus guardian must protect the static slots (controller) from each other. In the dynamic segment the bus 
guardian grants all controllers access to the bus. 
Comment: 

One of the main reasons for an error in tt\e time domain is an erroneous internal state that leads to an incorrect 
(timing) access to the communication media. 

20 

• Req : The bus guardian must be able to detect errors In the physical clocic source as well as errors in the internal 
representation of the time base of the communication controller. 

Comment: 

One of the main reasons for an error in the time domain is an error in the clock source of the communication 
25 controller Hence, the clock source check mechanism of the bus guardian must concentrate on the msun physKally 

possible failure modes of the clock source of the communication controller 

The bus guardian may have a clock source of its own. Two bus guardians, which are connected to the same 
communication controller can use the same clock source. 

30 • Reg: The bus guardian must not disable access to more than one channel, i.e., one bus guardian per channel is 
required. 

• Req : It must be possible to implement the bus guardian as a stand-alone circuit. This circuit has to be combinable 
with the known state of the art physical layers. 

35 Comment: 

The bus guardian could be integrated in the bus driver The lnterface(s) towards the communication controller (and 

the bus driver) must be defined. 

• Req : It must be possible to implement the bus guardian as a stand-alone circuit in the star coupler. This circuit has 
40 to interact with the Icnown state of the art physical layer. 

• Req : The bus guardian has to checl< the con'ect enabling of the driver output stage. 

• Req : The mechanism of separating the communication controller from the communication media must be checl<ed. 
45 At least once per driving cycle (power on / power off) is sufficient. 

• Req : The bus guardian Is configured via a configuration data interface. 

• Reg : The bus guardian has to enable and disable the bus driver output stage according to a predefined timing 
50 pattern. If the bus guardian detects an error In the timing pattern of the communication controller it permanently 

disables access to the communication media and signals this. 

• Req : If an error in the bus guardian occurs the communication channel must not be disturbed (monopolized). 

55 * Req : The configuration data Interface must be specified and documented. This mainly includes the logical contents 
of the timing pattern. 
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Wake-up 
[0065] 

5 • Reg : Several wake-up mechanisms have to be taken into consideration. 
ECU Bus Driver 
[0066] 

10 

• Reg : The bus driver has to be woken up by any source inside or outside the ECU (local wake-up). 

• Reg : The wake has to be two edge sensitive. 
Example: 

15 e.g., edge at a WU pin of the BD 

Bus ^ Bus Driver 
[0067] 

20 

• Reg : From the host's point of view a general wake-up mechanism is required for both electrical and optical systems. 

• Reg : The bus driver should be woken up via standard communication (message-pattern). 

25 * Reg : The wake-up detector has to be robust against disturbances in vehicles like common mode signals by emis- 
sion. 

• Reg : The bus driver may not be woken up by any noise. 
30 Bus Driver Controiler 

[0068] 

• Reg : The bus driver has to wake up the controller by any signal on the interface. A dedicated wake-up line is not 

35 reguired. 

Example: 

e.g., edge at the Rx pin produced by the bus driver 
Bus Driver Power Supply 

40 

[0069] 

• Reg : The bus driver has to signal its sleep state, e.g., to control the voltage regulator. 
Exampie: 

45 inhibit signal 

Controller Bus Driver 
[0070] 

50 

• Reg : The controller must be able to wake-up the bus driver by any signal on the interface. A dedicated wake-up 
line is not required. 

Example: 

Edge at the Tx pin 

55 
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Selective Sleep 
[0071] 

5 • Reg : The realisation of selective sleep has to be supported. 
Interfaces 

[0072] The interfaces between the single modules (host, controller, bus driver, bus guardian, and power supply) have 
10 to be agreed upon among the suppliers according to the general requirements defined in this document. Figure 17 
shows an overview of all interfaces. 

Host <^ Communication Controller (CHI) 

15 General Requirements 

[0073] 

• Reg: The configuration data of the communication controllers must be securable (e.g., by soft reset) against ac- 
20 cidental access and modifications. 

• Reg : Protect against improper host modification of BG and CC configuration data. 

• Reg : The Interface between the host and the communication controller should be implemented as a 1 6 bit Interface 
25 (selectable multiplexed/non-multiplexed bus Interface). 

• Reg : Functional compatibility between different suppliers has to be guaranteed at CHI level. 

• Reg : The CHI has to be configurable into transmit and dedicated receive buffers and receive buffers with FIFO 
30 behavior. 

• Reg : If the FIFO queue Is full and new data arrives the oldest data is overwritten. The FIFO queue must set a 
diagnosis bit when data in the buffer is oven/vritten. 

35 t Reg : MSB first is used for Frame Iransmission, 
Comment: 

The status area of the CHI contains communication controller status fields, which are written by the controller and 
which are read-only for the host. The status fields will be defined in the protocol specification and interface spec- 
ification. 

40 The control area in the CHI contains fields that allow the host to control the behavior of the communication controller. 

The control fields will be defined in the protocol specification and interlace specification. 
The message area in the CHI contains a memory area where the frames to be sent I received are stored together 
with status Information for each frame. The layout of this memory area is determined in the configuration data of 
each communication controller The message buffer status fields will be defined in the protocol specification and 

45 interface specification. 

• Reg : Support of traceability of system- and component-level faults to identify root causes of failures. 

• Req : The hardware Implementation should verify that only one combination of frame ID and sync bit is considered 

50 valid for transmission. 

Frame Filtering and IVIasi<ing 
[0074] 

55 

• Req : Message Reception, every message buffer has to contain a channel, frame ID and cycle counter which are 
used for message filtering. Optionally the first two data bytes of each message buffer are used as message ID filter. 
Options for filtering: 
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1) Frame ID + channel 

2) Frame ID + cycle counter + channel 

3) Message ID + cycle counter + channel 
Comment: 

s Filtering: Filtering of messages means that for each message buffer the message's frame ID, cycle count and 

message ID are parameters that define in which message buffer the correctly (correct CRC, time, etc.) received 
messages is stored or if the message is discarded. 

• Reg : There must be at least one mask register per communication controller and channel that allows all combina- 
10 tions of masking. 

Comment: 

Masking: Masking of message filters means that some (parts) of the filtering parameters may be configured to be 

disregarded (set to "don't care"). 

15 t Reg : Message transmission, filtering parameters for transmission are frame ID and cycle counter; there is no 
masking possible for the frame ID. Each transmit buffer has its own mask for the cycle counter. 

Interrupts 

20 [0075] 

• Reg : The host computer has to be able to request different interrupts from the communication controller: at least 
read interrupt (buffer), write interrupt (buffer), 2 independent timer interrupts. 

25 • Req : Timer interrupt: the host can request a time interrupt at any absolute point in the global time (across com- 
munication cycle borders). 

• Reg : One interrupt line is required for a standalone controller implementation. 

30 • Reg : Interrupts can be mapped to one or more interrupt lines in an integrated controller. 
Host o Bus Guardian 
[0076] 

35 

• Req : The bus guardian configuration data is written during download and then stored in a local memory of the bus 

guardian. 

• Reg : During normal operation no configuration data transfer from the host to the bus guardian is allowed. 

40 

• Reg : The bus guardian periodically updates a status field which can be accessed by the host / bus guardian 
interface containing at least the following status information: 

• State of the bus 

45 

• State of the controller 
Communication Controller <^ Bus Guardian 

50 [0077] 

• Reg : At least the following control information is required: 

• Arm signal 

55 
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Communication Controiier Bus Driver 
[0078] 

5 • Reg : This interface has to be confirmed among the suppliers. 
Example: 
Tx, TxEnable 
Rx, RxEnable 

10 Bus Guardian o Bus Driver 

Bus Driver o Power Supply 

[0079] 

15 

• Reg : To perform the wal<e-up and sleep functionality an interface between bus driver and power supply is required. 
Error Handiing 

20 [0080] The communication system and Its components shall offer adequate error management mechanisms to deal 
with faults arising from the following levels: 

• media 

25 • bit (coding) 

• frame 

• data 

30 

• topology and 

• time. 

The communication system furthermore shall offer diagnosis information to the host computer with respect to 

35 controller, bus (channel), and incoming/outgoing linl< failures. 

Requirements 

[0081] 

40 

• Reg : The error management shall follow the "never-give-up" philosophy. 
Ckmment: 

This means that the communication protocol has to support proper operation until a certain critical error states is 
reached. 

45 

• Reg : The non-arrival of periodic messages shall not be unrecognized. 
Comment: 

It is okay, if, e.g. one, periodic message is missed, but this has to be detected. The fact, that a periodic message 
was missed should be signaled to the host 

50 

• Reg : If a periodic message was missed, no random data shall be given to the host. 

• Reg : Data content of messages, (periodic and spontaneous) must not be changed by the communication protocol. 
55 • Reg : The change of data content shall be signaled to the host. 

• Reg: After an error was detected at a communication partner in the network, the functionality of the other commu- 
nication partners shall not be Influenced. 
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Comment: 

The correct function may not depend from the correct function of a certain host, of a certain communication con- 
troller or of a certain power supply. 

The communication controller shall detect the following list of errors: 

5 

• Reg : Synchronization error. The communication controller is not any more synchronized to the global time on the 
bus. 

• Reg : The communication network must offer diagnosis information to the host computer with respect to the bus 
10 (channel), incoming/outgoing link failures. 

• Req: The communication network must offer diagnosis information to the host computer within a defined maximum 
delay after the occurrence of the failure of the diagnosis element. 

15 t Reg : The communication network is not reguired to provide consistent and agreed diagnosis information to the 
host computer. 

Hardware Units 

20 [0082] The following faults have at least to be detected by the communication controller: 

• Req : Defect time source (e.g., broken crystal). 

• Reg : Low voltage. 

25 The following faults has to be recognized by the bus driver as errors: 

• Reg : Faulty communication signals caused by e.g. any faulty transmission media (e.g., a broken line, short circuit 
to ground,...). 

30 • Reg : Incon-ect communication with the host e.g., communication via the data interface. 

• Reg : Incon-ect communication with the communication controller e.g., bus-blocking transmit signals. 

• Reg : De-activated branch. 

35 

Interfaces 
[0083] 

40 • Reg : Status information on detected errors must be provided. Additionally it is reguired that maskable interrupts 
for certain detected errors can be requested by the host. 

Constant Definitions 

45 [0084] In this section the constants for a number of design parameters defined throughout the document are set to 

actual values. 

Communication Network Constants (iVIin/IVlax) 
50 [0085] 

Table 3: 



Definition of the constants used throughout the specification. 


Name 


Value 


Description 


CONTROLLER_MAX 


64 


Maximum number of controllers connected to one communication channel. 


CYCLE_LENGTH_MIN 


250 iiS 


Minimum length of the configurable communication cycle. 
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Table 3: (continued) 



Definition of the constants used throughout the specification. 


Name 


Value 


Description 


CYCLE_LENGTH_IVIAX 


64 ms 


l\/laximum length of the configurable communication cycle. 


DATA_BYTES_IVIAX 


246 


Maximum number of data bytes. 


DYNAIVIIC_IDS 


4095 


Maximum number of dynamic identifiers. 


STATIC_SLOTS_IVIIN 


2 


Minimum number of static slots in a static segment of a communication cycle 


STATIC_SL0TS_I\/1AX 


4095 


Maximum number of static slots in a static segment of a communication cycle 
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Glossary 
[0086] 

Bus 

Bus Driver 
Bus Guardian 

byteflight 

Channel 

CHI 
Clique 

Cluster 

Cluster time 

Communication Controller A 
Communication Cycle 

Controller 

CRC 
CYCLE 



Consists of one or several channels. 

A bus driver connects a communication controller to one channel. 

A bus guardian protects one channel from timing failures of the communication con- 
troller. It is therefore connected to one communication controller and one bus driver. 
The bus guardian must be independent from the protocol communication controller. 

Communication networic developed by BMW AG, Motorola, ELMOS, Infineon, Sie- 
mens EC, Steinbeis Transferzentrum fur Prozessautomatisierung, IXXAT. (See http:// 
www.byteflight.com) 

A channel is a physical connection between several communication controllers. A re- 
dundant channel consists of two channels connecting the same communication con- 
trollers. 

Controller Host Interface. 

Set of communication controllers having the same view of certain system properties, 
e.g., the global time value, or the activity state of communication controllers. 

Synonym for networic within this specification. 

Same as cycle time. 

communication controller is connected to one or two channels where it can send and 
receive frames. 

Periodic data transfer mechanism. Structure and timing are statically defined. Howev- 
er, a static and a dynamic segment allows for the transmission of both, state and event 
information. 

see, Communication Controlier. 

Cyclic Redundancy Code attached to a frame. 

The CYCLE field is used to transmit the cycle counter. The cycle counter Is Increased 
simultaneously in all nodes by the communication controller at the start of each new 
communication cycle. 



Cycle Counter 



Contains the number of the current communication cycle. 
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Cycle time 

DATA 
DLC; 

Dynamic Segment 
EOF 



15 



ECU 
EiVIC 
20 FIFO 
Frame 

25 FTA 



30 



FTM 



Gateway 
Global time 
Hamming Distance 
Host 

ID 



Identifier 
IFG 
LEN 
LLI 



Contains the time within a communication cycle in units of macroticks. Same as cluster 

time. 

Data field In a frame. 
Data length field 

Segment of the communication cycle where frames are transmitted according to a 
minl-slotting algorithm. The sending order is defined by a statically determined identi- 
fier. Identifiers with smaller numbers have priority over identifiers with higher numbers. 
A communication cycle may consist of the static segment only. 

End Of Frame. An optical or electrical physical layer may require different end of frame 
sequences. 

Electronic Control Unit. Same as node. 
Electro Magnetic Compatibility. 

First In First Out. Buffers can be configured to work as a FIFO memory for frames. 

A frame consists of all Infonnation transmitted in one slot (with one identifier) on one 
channel. 

Fault Tolerant Average. The FTA is a fault tolerant cloci< synchronization algorithm that 
is able to tolerate up to a pre-defined number /c of maliciously faulty clocks. This algo- 
rithm Is based on a sorted array of clock deviations. The lower and upper k clock de- 
viation values are discarded. From the remaining clock deviation values the average 
value is calculated and then used for the clock correction. 

Fault Tolerant IVIidpoint. The FTM is a fault tolerant clock synchronization algorithm 
that Is able to tolerate up to a pre-defined number k of maliciously faulty clocks. This 
algorithm is based on a sorted array of clock deviations. The lower and upper k clock 
deviation values are discarded. From the remaining clock deviation values the median 
value is chosen for the cloci< correction. 

A node may function as a gateway and connect two or more networks. 
Contains the combination of cycle counter and cluster time. 
Minimum distance of any two code words within a code. 

The host is the part of an ECU where the application software is executed, separated 
by the CHI from the communication network. 

The frame Identifier defines tine slot position In the static segment and defines the 
priority in the dynamic segment, A lower identifier determines a higher priority. Identifier 
0 is reserved for the SOC symbol. The identifier of a frame must be unique within a 
cluster Each controller can have one or more identifiers (in the static and the dynamic 
segment). 

see, ID. 

Inter Frame Gap. 
Length field of a frame. 
Logical Line Interface. 
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LSB 
MAC 
5 Macrotick 

Message 

10 

Microtick 

15 

MSB 
Network 

20 

Node 

25 Nominal Precision 

NRZ 
30 Precision 

35 Slot 

soc 

40 

SOF 

Star Coupler 

45 

static Segment 

50 SYNC 
TDMA 



Least Significant Bit/Byte. 
Media Access Control. 

Basic unit of time measurement witliin a network of communication controllers. The 
clock synchronization mechanism guarantees that the dock values at all non-faulty 
controllers are equal. The uncertainty in the clock values is bounded by the precision. 

Application data transported within a frame. Several messages may be packed togeth- 
er to constitute a frame. 

Basic unit of time measurement within a communication controiler for measuring the 
time difference between the controllers clock and the clocks of the other communica- 
tion controllers. Clock correction is done in units of Microtick. 

Most Significant Bit/Byte. 

A network consists of a set of nodes (more than one node) connected by communica- 
tion subsystem. Networks are connected by special nodes (gateways). Same as Clus- 
ter. 

A node may contain one or more communication controllers. Equivalent to £CL/ (Elec- 
tronic Control Unit). 

The nominai precision is the ciock synchronization precision that can be reached by 
the iocai clock synchronization of a cluster 

Non Return to Zero physical layer coding scheme. 

The precision is a time interval bounding the deviations between the local clocks of all 
active communication controllers. If a communication controllers clock deviates more 
than the precision from the clocks of the other controllers it must not participate in the 
communication any longer. 

Duration of time during which one communication controller may access the commu- 
nication medium. 

Start of Cycle. Defines the start of a communication cycle in the pure dynamic mode, 
and the start of communication for start-up. 

Start of Frame. An optical or electrical physical layer may require different start of frame 
sequences. 

A star coupler is connected to one channel. 

Segment of the communication cycle where frames are transmitted according to a 
statically defined TDMA scheme. A communication cycle may consist of the static seg- 
ment only. 

Synchronization field. This field indicates that the slot is used forelock synchronization . 
Time Division Multiple Access. 
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Index 



30 



A 

application 

layer 10 

arm 

signal 41 

asynunetric 24 

B 

baud rate 27 

bit 

decoding 34 

encoding 

mz 34 

synchronization 34 

timing 34 

bus 

driver, electrical ....34 

driver, optical 34 

guardian 9 

bytef light 34 

compatibility 15 

C 

clique 24 

clock 

external 

synchronizatio 

n 26 

synchronization 23 



alogorithm 25 

measurement 25 

scalability 24 

conununication 

controller 33 

cycle 

counter 18 

dynamic segment 17 

length 16 

static segment 16 

structure 15 

CONTROLLER_MAX 13 

CRC 15 

current 

consumption 32 

cycle 

time 23 

CYCLE_LENGTH_MAX 16 

D 

dominant 

bits 20 

E 

ECU 

architecture 10 

EMC 31 

external 

correction 
term 2S 
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F 

frame 

coding 19 

format 17 

timing 20 

FTM 25 

G 

global 

time 23, 24 

H 

Hamming 

distance 15. 

hardware 27 

I 

identifier 18, 19 

interface 39 

bus driver - power 

supply 42 

bus guardian - bus 

driver 42 

communication 

controller - 

bus driver 41 

communication 

controller - 

bus guardian 41 

host - bus guardian ...41 
host - 

communication 

controller 3 9 

interrupt 41 

J 

jitter 9 



X 

latency 9 

logical 

line 34 

M 

Mbit/s 13, 15 

medium 

access 16 

message 

transfer 11 

microtick 23 

multiplexing 19 

ir 

network 

configuration 11 

node 

architecture 10 

Null frame indication 

field 18 

P 

physical 

layer 10 

physical layer 

electrical 20 

optical 19 

power 

consumption 31 

mode 27 

supply 13 

power modes 33 

precision 23 

presentation 

layer 10 

protocol 

description 15 

pure 
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dynamic 15 

static 15 

S 

scalable 

fault tolerance 9 

shutdown 23 

SOC 23 

SOF 21 

window 25 

soft reset 39 

start-up 21 

STATIC_SLOTS_MAX 13, 16 

STATIC_SLOTS_MIN 16 

synchronization 

error 44 

field 18 

T 

TDMA 16 

temperature 31 

timer 

interrupt 41 

topology 11, 27 

heterogeneous 22 

transfer 

layer 10 

V 

voltage 

battery 32 

monitoring 35 

supply 32 

W 

wake-up 27, 37 
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Chapter 1 
Introduction 

Objectives / Scope of PWD 

[0087] To design a new protocol new ideas wiii be created, discussed and developed. To coiiect aii of tliese ideas, 
the protocol worl<ing document (PWD) was created. In the appendix the documentation of the technical discussion is 
done. This means that different approaches and solutions are listed and reasons are found and documented to decide 
for one solution. 

[0088] Parts which are agreed and which will not change in the future significantly will be well documented moves 
to the main part. These chapters wiii be the base for the protocol specification. 

[0089] Tine owner of the PWD is the FlexRay consortium. Members are BMW, DaimlerChrysler, Philips, Bosch, Gen- 
eral Motors and Motorola. All of these companies deliver input to the appendix but only one editor (Motorola) handles 
the inclusion in the document. 
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Terminoiogy 

[0090] 

Application 
Data 



Bus 



Bus idle Clique 



Cluster 



Communication 
Channel 



Communication cycle Correct frame Cycle time 
Dynamic part Encoded Packet 

Frame 



Header Message 
Message Instance 

Network 
Node 



55 Packet 



Payload Star 



Data produced and/or used by application 

tasks, in the automotive context the temn 'signal' is often used 

for application data exchanged among tasks 

A communication channel in bus topology. Sometimes the word 

"bus" is used as synonym for communication channel. 

A subset of nodes (and stars) in a cluster which understand 

each other but do not understand the nodes (and stars) outside 

of this clique. The existence of cliques is usually an failure and 

protocol mechanisms try to avoid the generation of cliques. 

A communication system is called cluster if two or more nodes 

are connected via at least one communication channel directly 

(bus topology) or by star couplers (star topology). Two or more 

cluster built a network. 

The physical connection between node/node, 

star/star, node/star or star/ node. The physical connection can 

work electrical or optical. 

Time for one communication cycle. 

A packet encoded for transport on the physical communication 
media using, for example, NRZ 8N1 or Xerxes coding 
A Structure used by the communication system to exchange 
information within the system, a frame consists of a header sec- 
tion, a payload section and afooter section; the payload section 
contains data fields, in which a message instance is copied. 
A block of application data (signals) to be exchanged among 
tasks (ECUs) 

One copy of a message that is transmitted by the communica- 
tion system. At the receiver multiple message instances may 
be used to generate a new single message by using, for exam- 
ple, an agreement algorithm. 

A network is a communication system built with clusters which 
are coupled via gateways. 

A unit built with a communication controller, a host CPU and a 
(quartz) oscillator. The communication controller is connected 
at least to one communication channel. 
A frame or symbol amended with physical layer specific ele- 
ments ; so far these elements are the frame-start-sequence, the 
start-of-frame symbol and the frame-end-sequence. 
A unit that connects nodes and others stars. Every star has 
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more than two inputs/outputs. A star can be passive or active. 
Static part Part of the communication access time sclieme wiiere tine me- 

dia access wori<s witii a time division media access (TDIVIA). 
This means that every node owns one or more time slots stat- 
ically and only this node is allow to write on the communication 
channel during this time. 

Sync frame 

Trailer Frame which Is marked to use for clock synchronization. 



10 Variable and Parameter Names 



[0091] Following is a description of the notation of variables, constants and parameters how It Is used to document 
in the PWD and in the protocol specification. 

15 Table 4: 



Naming Conventions 


Naming 
Convention 


information Type 


Description 


cName 


Constant 


values used to define the protocol, Is fixed for the protocol and 
can not be changed 


vName 


Variabie 


values which will be changed depending on time, events, etc. 


gName 


Global Parameter 


parameter which must have the same value in ail nodes in a 
ciuster, is initialized during soft reset, can only be changed 
during soft reset 


pName 


Local Parameter 


parameter which may differ In nodes of a cluster, Is Initialized 
during soft reset, can only be changed during soft reset 


fName 


Variable for frame content 


f Name-variables are set in the transmitter node and read in the 
receiver node 


xdName 


Time Duration 


vaiue (variabie, parameter, etc.) describing a time duration, 
time between two time points 


xtName 


Time 


value (variable, constant, etc.) describing a Instant 


xsName 


Set 


set of values (variables, parameters, etc.) 


X 




stands for one of c, v, g, or p 



40 Code Conventions 



[0092] To specify functions and algorithms short code pieces are used. For the notation of this code the IVIATLAB 
syntax Is used. Following Is a short description of the used functions and elements. 



Table 5: 



Pseudocode Conventions 


Function or 
Element 


Description 


x=LENGTH(iist) 


returns the number of elements of the list "list" 


llst= [list, X] 


appends the list "list" by the element "x" at the end of the list 


X = list(i) 


X is the eiement 1 of the list "list" 


x= SORT(iist) 


returns a sorted iist of list "list" following: list(1) >= list(2) >= list(3) >= >= iist(n-1) >= list(n) 


x= MIN(a,b) 


minimum, returns a if a < b, otherwise b; if a invalid returns b, if b invalid returns a, if a and 
b invalid returns an empty set 
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Table 5: (continued) 



Pseudocode Conventions 


Function or 

Element 


Description 


x= MIDTERM(list) 


fault tolerant midterm algorithm, see section Fault-tolerant Midpoint Aigoritiim 


x= lnt[a] 


returns tiie Integer part of the (real) number a 


x= lal 


returns the absolute value of a (a without sign) 



Chapter 2 

Basic Concepts (Prerequisites) 

15 

Protocoi Layers 
Arcliitecture 
20 Networic Topologies 

[0093] A network can be configured as a single-channel or dual-channel bus network, a single-channel or dual- 
channel star network. 



Bus Topology 

[0094] Figure 18 shows the possible topology configuration of the communication network as a dual bus. A node 
can either bo connected to both channels 0 and 1 (nodes A, C, and E), only to channel 0 (node D) or only to channel 
1 (node B). 

[0095] The FlexRay communication network can also be a single bus. In this case, all nodes are connected to this bus. 



Star Topology 

Valid Star Network Configurations 

35 

[0096] A FlexRay communication network can be built as a multiple star topology. Similar to the bus topology, the 
multiple star topology can be set up redundantly. Each network channel must be free of closed rings, and there may 
only be 1 up to cSfarCoup/crs/Wax sequentially connected (cascaded) star couplers (the total number of star couplers 
may be more than cStarCouplersMax\1 there are branches In the network). Each network line between communication 
node and the star coupler or between two star couplers represents a properly terminated polnt-to-point connection. 
The incoming signal received by the star coupler is actively driven to all communication nodes Figure 1 9 shows a single 
redundant star coupler configuration 

[0097] OpenTopIc: We assume that the star coupler drives all connected nodes and star couplers except the recep- 
tion line. Also we assume that one a line erroneously driven by the star coupler and another instance will show a signal 
^5 causing an encoding error in any case. We assume that other lines driven by the star coupler are not affected by such 
a conflict. 

[0098] If two or more inputs of the star coupler are start to be driven at the same time or in a time window shorter 
than gdBitvie assume that one of this will cause a signal with encoding violation on all outputs driven by the star coupler. 
[0099] SUGGESTION: this is part of the error model or star node description IVIJ). 
50 Figure 20 shows a single channel network with three star couplers. 

[0100] The configuration of a single redundant star network is shown in Figure 19. The logical structure of this topology 
is identical with the logical bus structure shown In Figure 18. A topology which has a single non-redundant star, which 
has the logical bus structure of the single bus mentioned above, Is also possible. 

[0101] Figure 20 shows a single channel network built with three star couplers. Each node has a point-to-point- 
55 connection to one of the three star couplers. Two of the star couplers (No. 1 and 3) are directly connected to the third 
star coupler (No. 2). 

[0102] Open Topic: A mixed star/bus topology is not yet discussed. 
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Star Coupler Behavior and Protocol Impact 

[0103] Open Topic: What is the complete state diagram for the star coupler (later there is mentioned an "initial 
state")? Does it support a sleep mode, and if so has the wake-up an impact on the protocol? Does it have a reset state, 

5 a startup state or an error state? How is It tested? How does it behave after a short power down? 

[0104] Open Topic: Open topic: For the modeling project it is assumed that ail connections of a star coupler are set 
up for reception per default. When the first bits (this time is called "configuration setup delay" and Is configurable in 
the model) of a Frame Start sequence are detected on one receive line this causes the other receive lines to be 
reconfigured for transmission. A sequence of correctly encoded bits is assumed to cause this reconfiguration, though 

10 (pessimistic assumption). Noise does not cause this reconfiguration, if the condition forthis reconfiguration is observed 
on two or more receive lines within a time window of 1 gdBitlhe star coupler generates a signal with illegal encoding 
on all other lines that will then be reconfigured as transmit lines. Actually in the model the same signal is generated 
like for a bus with overlapping frames. 

This reconfiguration remains until an idle signal is recognized on (all) the receive iine(s). As soon as this is recognized 

'5 all lines are reset to the default configuration. 

• For each node connected to a star coupler, the star coupler contains a bi-directional connection operating in half- 
duplex mode. 

20 • Before transmitting a frame, the connections must be set up as either receive or send in each star coupler 

• The frame format in FlexRay defines a Frame Start Sequence (FSS, see xxx), which is used to initiate a proper 

connection setup throughout the network before the actual FlexRay message is transmitted. The transmission of 
the FSS is interpreted and handled by the star coupler as a connection setup request. There is no Frame End 
25 Sequence defined in FlexRay, and the star coupler is returned to it's idle state after the bus has been released to 

the idle state by the last transmitting node. 

[0105] Open Topic: Should there be a frame end sequence? 

30 * The detection of activity generated by the FSS transmission causes the star coupler to turn on the driver devices 
accordingly. The line on which activity was first monitored remains the input to the star coupler, i.e. available for 
the reception of the message sent by the transmitting node. The star coupler activates all remaining line drivers 
as outputs to the nodes and other star couplers that should receive the message. 

35 t The FSS may degenerate by propagating through the star coupler. 

• The FSS must be detected by all cascaded star couplers and by ail receiving end nodes in the network. This 
imposes requirements on the minimum length of the Frame Start sequence, since each communication element 
consumes a portion of the Frame Start sequence. Table 6 gives an overview of maximum configuration setup 

40 delays. 

[0106] Open Topic: What does "Detection Events" mean and does this term make sense in a point to point config- 
uration? 

[0107] Open Topic: Is this table valid for optical and electrical transmission medium? 
45 [0108] Open Topic: 'Detection Events' actually means 'Detectors' i.e. in a point to point, there Is only one detector 
- the receiving node - and no portion of the Frame Start sequence is consumed, in a single star network, there are two 
detectors - star-coupler and receiving node - and the first of those will consume part of the Frame Start sequence, and 
so on. The polnt-to-point connection defines the minimum Frame Start sequence and so does make sense to Include 
it in this table. 

50 [0109] Open Topic: needs to be clarified, but probably isn't due to the different optical device characteristics. 

[01 1 0] Comment: Detection Events detailed in Table 6 actually means 'Detectors' i.e. In a point to point or broadcast 
bus topology, there is only one detector - the receiving node - and no portion of the FSS is consumed, in a single star 
network, there are two detectors - star-coupler and receiving node - and the first of those will consume part of the 
Frame Start sequence, and so on. The point-to-point connection defines the minimum FSS. 

55 
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Table 6: 



Maximum Frame Start Sequence Durations wrt Network Topology 


Network 
Topology 


Detection 
Events 


Frame Start 
Sequence [ns] 


e.g. number 
ofgdBit® 10 
Mbps 


Point to point/Bus 


1 


200 


2 


Single Star 


2 


400 


4 


2 Cascaded Star Couplers (not supported FPGA V4) 


3 


600 


6 


3 Cascaded Star Couplers (not supported FPGA V4) 


4 


800 


8 



• At the end of each frame transmission, all star couplers must return to the initial state before the next configuration 
request Is initiated. This ensures that the star coupler Is able to process the next configuration request correctly. 



• The overall time needed to return a network to the initial state is determined by the individual configuration release 
delays in the star couplers. In a cascaded star coupler network, these delays sum up, similar to the configuration 
setup delays. Table 7 gives an overview of the maximum configuration release delays. 



Table 7: 



Maximum Release Sequence Durations wrt Network Topology 


Network 
Topology 


Release 
Events 


Release 
Sequence [ns] 


e.g. number 
ofgdBit® 10 
Mbps 


Point to point/Bus 


1 


200 


2 


Single Star 


2 


400 


4 


2 Cascaded Star Couplers (not supported FPGA V4) 


3 


600 


6 


3 Cascaded Star Couplers (not supported FPGA V4) 


4 


800 


8 



• The minimum idle time between two consccutivciy transmitted frames must accomodate both the Release and 
Detection events detailed in the above tables, (overall configuration release delay and the overall configuration 
setup delays) 



[0111] Comment: Consolidate terminology: communication channel, bus, star 
Node Architecture 



[01 1 2] Figure 21 shows an example of the architecture of a node. 

Every node consists of the four sub-components host, communication controller, bus guardian and physical driver 
The sub-components may be discrete, or certain combinations of them may be integrated together e.g. bus guardian 
and physical layer (as shown) and host and communications controller. 



Protocol Services 



0113] 

Message transfer 
Synchronized time base 

Sleep, Shutdown 



Diagnosis 



37 



5/19/2010, EAST Version: 2.4.1.1 



EP 1 355 456 A1 



Dependability issues 
Faiiure Resilience Requirements 
5 Assumed Fault Models 
Assumed Fault Hypothesis 
Design Principles 

10 

Chapter 4 

Media Access Scheme 

15 [0114] In FlexRay media access is performed witliin a periodically recurring communication cycle. Tine structure of 
tfiis communication cycle is described in this section. 

[0115] Within one communication cycle FlexRay offers the choice of two media access schemes. These are 

• a static time division multiple access (TDMA) scheme (static segment), and 

20 

• a dynamic bytefllght-compatlble minl-slotting based scheme (dynamic segment). 

[0116] The duration of each segment is configurable. A pure static mode, a mixed mode containing a static as well 
as a dynamic scheme and a pure dynamic mode may be configured. Section "Static Segment (TDMA Access)" of the 
25 specification focuses on the static TDMA scheme and Section "Dynamic Segment" covers the dynamic mini-slotting 

based scheme. 

[0117] The FlexRay protocol offers the option of implementingclusters with a single communication channel (channel 
A only) or with dual communication channels (channel A and channel B). In the case of a dual channel cluster the 
channels are synchronized to one another. In the dual channel case nodes may be connected to either one or both of 
30 the communication channels. Dual channel systems support nodes connected to only one of the communications 
channels of the cluster. Such single channel nodes can be connected to either channel A or channel B. 

Communication Cycle 

35 [0118] The communication cycle is the fundamental element of the media access scheme within FlexRay. In order 
to accommodate both communication schemes within one communication cycle the communication cycle consists of 
a combination of two segments: a static segment and a dynamic segment. 

• Within the static segment the static TDMA scheme Is used to control access to the communication media. 

40 

• The Internally synchronized time base of each communication controller controls the static TDMA scheme. 

• Within the dynamic segment the minl-slotting based scheme Is used to access to communication media. 
45 » A Dynamic Communication Trigger (DCT) Initiates the minl-slotting scheme. 

• The communication cycle is concluded by acommunlcation traffic free period known as the Network Idle Time (NIT). 

• The maximum duration of a communication cycle Is cdCycleTimeMax. 

50 

• The duration of the communication cycle is set in gdCycleTime such that gdCycleTime <= cdCycleTimeMax. 
[0119] Depending on the type of configuration either one or both segments exist: 

55 • In a pure static configuration only the static segment exists. 

• in a mixed static/dynamic configuration the static segment Is succeeded by the dynamic segment. 
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• The DCT is derived from tlie synciironized time base. 

• Each node triggers the DCT at the end of the static segment. 
5 • In a pure dynamic configuration oniy the dynamic segment exists. 

• The DCT is derived from an expiicitiy sent Start of Cycie (SOC) symboi. 

[0120] The avaiiabiiity of the different configurations differ between the FiexRay mode and bytef light mode: 

10 

• In FlexRay mode it is possible to chose among the pure static, the mixed static/dynamic, or the pure dynamic 
configuration. 

• The FlexRay frame format is used for all configurations. 

15 

• In byteflight mode only the pure dynamic configuration is available. 

• The byteflight frame format is used. 

20 [0121] The interdependencies between operating mode, configuration, frame fonnat and media access schemes 
are summarized in Table 8. 



Table 8: 



Relationship between operating mode, configuration, frame format and media access scheme Figure 22 iliustrates 
the different communication cycle configurations that are avaiiabie. 


Mode 


Configuration 


Frame Format 


Static 
Segment 


DCT 


Dynamic 
Segment 


FlexRay 


Pure Static 


FlexRay 


exists 






Pure Dynamic 


FlexRay 


exists 


synchronized 
timebase 


exists 


Mixed Static/ 

Dynamic 


FlexRay 




SOC 


exists 


byteflight 


Pure Dynamic 


byteflight 




SOC 


exists 



Static Segment (TDMA Access) 



[0122] The communication cycle contains a static segment in 

• FlexRay mode pure static configuration and in 

• FlexRay mode mixed static/dynamic configuration. 

45 

Principle 

[0123] Within the static segment access to the communication media is controlled by a static Time Division IVIultiple 
Access (TDMA) scheme. 

50 

Structure 
[0124] 

• The static segment is divided into a number of static communication slots (or "static slots"). Within a given cluster 
all static slots have equal duration, which is an integral number of macroticl<s. 

• The duration of a static slot is defined by the parameter gdSlot in multiples of macroticks. 
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• The number of static slots available within a communication cycle is defined on a per cluster basis in gNumberOf- 

StaticSlots. 

• The overall duration of the static segment (in macroticks) is defined in gdStaticPart such that gdstaticPart = gdSlot 
5 * gNumberOfStaticSlots. 

• A unique slot ID ranging from 1 to gNumberOfStaticSlots is assigned to every static slot in ascending order starting 
with 1 . Slot IDs match on both channels. 

10 • The maximum number of static slots available in any FlexRay cluster is detennined by cStaticSlotMax. 

• The static segment starts with the start of the first static slot. 

• The start of a static slot coincides with the start of a macrotick. 

15 

• The static segment ends with the end of the last static slot. 
Slot Assignment 

20 [0125] 

• A static slot is assigned on a per channel basis to a specific communication controller for transmission. 

• A maximum of cStaticSlotMaxPerNode static slots may be assigned to a single communication controller. 

25 

• Static slots may remain unassigned. 

• Two different nodes can share a slot only if both nodes are single channel nodes and the nodes are connected to 
different channels of a dual channel system. 

30 

Frame transmission 
[0126] 

35 » Transmission of a frame occurs in the slot in which the slot ID matches the Frame ID. 

• Frames have a fixed length within the static slots. 

• A frame is only transmitted if the payload length code that is used in the frame matches the cluster-specific con- 
40 figuration parameter defining the payload length for static frames. (fPayloadLength is compared with gPayload- 

LengthStatic) 

Consequences 
45 [0127] 

• The frame ID determines the position of each frame within the static segment. 

• All frame ID'S are unique per communication channel during one communication cycle. 

50 

• Depending on the allocation of slots and of the configuration of a given node It sends either no, one or multiple 
frames within the static segment. 

[0128] As a result the following transmission patterns are possible: 

55 

• Assuming that for a given slot both channels are assigned to one communication controller, it is possible for the 

communication controller to send 
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1 . a frame with identical content on each of the two channels, as shown in Figure 24 (a), or 

2. a frame with different content on each of the two channels, as shown, for example, in Figure 24 (b), or 
5 3. a frame on one channel but no frame on the other channel, as shown, for example, in Figure 24 (c), or 

4. no frame at all, as shown in Figure 24 (e). 

• Assuming that for a given slot only one channel is assigned to one communication controller, it is possible for the 
10 communication controller to send 

1 . a frame on the assigned channel, as shown, for example, in Figure 24 (c) for channel A, and in Figure 24 
(d) for the case that the other channel Is assigned to another communication controller, or 

15 2. no frame at all, as shown, for example, in Figure 24 (c) for channel B and Figure 24 (e) for both channels, 

[0129] Figure 23 shows the transmission slot layout within the static segment of the communication cycle. 
[0130] Figure 24 shows the basic media access patterns for two channels, (add explanation of figure here) 

20 Frame Validation 

[0131] Receive buffers are only updated in Normal Mode; receive buffers are not updated during startup. 

[0132] All of the following (channel individual) checlcs must be successful for a static frame in a receiver before the 

frame may be copied into a receive buffer: 

25 

Context and coding checlcs 
[0133] 

30 • CheckldlebeforeFrame_x 

• CheckFrameCoding_x 

• CheckHeaderCRC_x 

35 

• CheckCRC_x 
Content checics 

40 [0134] 

• CheckFramelDStaticRange_x 

• CheckStaticPayloadLength_x 

45 

• CheckFramelD_x 

• CheckCycleCount_x 

50 • CheckReceivedPayloadLength_x 
Timing checiu 
[0135] 

55 

• CheckT_RW1_x 
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Dynamic Segment 

[0136] The communication cycie contains a dynamic segment in 
5 • FlexRay mode mixed static/dynamic configuration, in 

• FlexRay mode pure dynamic configuration, and in 

• bytefllght mode. 

10 

Principle 

[0137] Within the dynamic segment access to the communication media is controlled by a bytefllght-compatlble 
flexible time-division multiple access (FTDMA) scheme. 

15 

Overview 
[0138] 

20 • |\^edla arbitration is performed by means of priorities and slot counting. 

• The priorities are given by the frame ID'S. Priority is actually determined by the time the frame is sent (I.e., the slot 
counter value), The frame ID should be set to the same value as the slot counter, but If It is not it has no bearing 
on the priority (the frame wili be rejected, though). 

25 

• The highest priority equals the lowest frame ID. 

• If the dynamic segment Is preceded by a static segment then the highest priority is determined by the number 
of static slots reserved in the static segment. The highest priority in the dynamic segment is defined to be 

30 gNumberOfStaOcSlots + 1 . 

• Each priority, and thus each frame ID, is unique per communication channel for every communication cycle. 
Therefore a frame ID of a given value can appear only once per communication channel during one commu- 
nication cycle. 

35 

• Each node maintains channel specific slot counters denoted vSlotCounter_A and vSlotCounter_B respectively. 

• At the start of the dynamic segment the slot counters are initialized with gNumberOfStaticSlots. This accounts for 
the potential of a preceding static segment. In FlexRay pure dynamic or bytefllght mode gNumberOfStaticSlots is 

40 set to zero (0). 

• An ongoing frame reception from the static segment is aborted when the dynamic segment begins. The incomplete 
received frame is treated as an error (warning level) that is signaled to the host. The portion of the frame that 
remains in the dynamic segment is treated as bus activity and therefore will stop the slot counters in a manner 

45 similar to nomnal noise that is detected at the start of the dynamic segment. 

• For dual channel systems, the channels operate independently, independent operation means that there is no 
synchronization of the slot counters on the two channels. The beginning and end of the dynamic segment occurs 
at the same time for both channels, however. 

50 

Start of the dynamic segment 
[0139] 

55 • The dynamic segment starts with the dynamic communication trigger (OCT). 
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Mixed Static/Dynamic Configuration 
0140] 

In mixed static/dynamic configurations the OCT coincides with the end of the last static slot. 
All nodes are Initially considered receivers. 
Pure Dynamic Configuration 
0141] 

In pure dynamic configurations a predesignated node sends an SOC symbol. In this case the DCT coincides with 
the end of the SOC symbol. 

In a dual channel system the SOC is sent simultaneously on both communication channels. 

For a node connected to both channels in a dual channel system the first valid SOC that is received on either of 
the channels acts as the DCT for both channels. 

The node that sends the SOC symbol is the DCT transmitter, the remaining nodes are DCT receivers. 

• The DCT sender subsequently waits for the duration pdWxOTx+ pdWxDelta before incrementing the channel- 
specific local slot counter by one. 

• The DCT receivers subsequently wait forthe duration pclWxORx+ pdWxDelta before incrementing the channel- 
specific local slot counter by one. 

[0142] The following pseudocode describes the initialization and start of the dynamic segment. 



VSlotCounter x = gNumberOfStaticSlots; // 

// 

if pMaster == true and gNumberOfStaticSlots == 0 // 
Transmit SOC () ; // 
TimeOut ( pdWx OTx) ; // 
vdWaitTime = pdWxDelta; // The second 

part of the wait occurs in 

// the parallel section 

of the main 



// transceive loop 
else // 

vdiVaitrime = pdWxORx + pdWxDelta; // 
end; // 



50 [0143] Comment: When is the slot counter Incremented (Check, explain)? Proposal: put the pseudocode together; 
explain meaning vdWaitTlme. 

[0144] During the dynamic segment each node is engaged in one of three activities: waiting for a minislot in which 
it will transmit a frame, frame transmission, or monitoring channel activity and frame reception. These are described 
subsequently. Note that the following activities are perfonned independently for each communication channel. 
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Waiting 
[0145] 

5 • The node waits for an initial duration that is either pdWxOTx or pdWxORx. 

• The siot counter is subsequentiy incremented by one after each pdwxDelta period of time passes. 
Frame transmission 

10 

[0146] 

• If the frame ID of a frame that is scheduled for transmission matches the value of the slot counter the respective 
frame is transmitted. 

15 

• After finishing transmission the sender waits for pdWxOTx w+ pdWxDelta. However, during the period of pdWxOTx 
the sender disables its receiver. 

• A frame is only transmitted if the value calculated for fPayloadLength_x Is not greater than the maximum allowed 
20 value according to the frame format definition. 

Channel activity and frame reception 

[0147] 

25 

• Any channel activity causes the slot counting mechanism to stop. 

• If a frame transfer is causing the channel activily, the frame Is received. 
30 • Once the channel activity ends the node waits for pdlVxOflx+pdlVxDe/fa. 

• If the frame ID of the received frame differs by one compared to the respective slot counter then the respective 
slot counter is readjusted to the value of the received frame ID. 

35 [0148] The following pseudocode summarized the three activities described above 
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while vSlotCounter x <= cSlotlDMax 



if NextScheduledFrameID_x == 
<= pdLatestTX // 

Transmit Frame ( ) ; 
Timeout ipdWxOTx) ; 
vdWaitTime = pdWxDelta: 
end; 

terminate ends the 

parallel 
section: this is either 

{timeout vdWaitTime}; 
next minislot 

{monitor channel In- 
activity 
end; 

if vChannelActivity_x == true 
Receive Frame ( ) ; 



// 



vSlotCounter x AND vMacrotick 



// 
// 



II 



II 



II first task to 
// parallel 

//a timeout - 
// or channel 

// 

// 



// 



// 

if (CheckFrameIDDynamicRange_x == *T' ) 
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if { { {fF]:ameID_x + 1) == vSlotCounter_x ) OR // 
correct frame ID if missmatch by 

{{fFrameID_x - 1) == vSlotCounter_x )) II one 

vSlotQounter_x. = fFrameID__x; II 
end; ~ // 

// if the received 

frame has a frame 

if [vSlotCounter != fFrameID_x) 1/ ID that 

is valid for the dynamic 

{ signal slot missmatch error}; // segment 

the frame is stored 

end; // regardless whether 

it has caused 

// a slot missmatch or 

not 

{store received frame using fFramelD); 
else 

{signal slot missmatch error}; 

end; 

vdWaitTime = pdNxORx + pdWxDelta; II 
end; // 
end; // 



Pseudocode: {timeout vdWaitTijne} 



TimeOut (vdWaitTime) ; // 
VSlotCounter_x++: II 
VdWaitTime = pdWxDelta; II 



Pseudocode: {monitor channel} 



while vChannelActivity_x == false // 
end; // 



[0149] In the pseudocode above, the function ReceiveFrame() performs frame validation. This function returns 

• at the end of a correct frame or 

• as soon as an error Is detectable and channel idle is signaled 
Termination of the Dynamic Segment 

[0150] The dynamic segment terminates if either of the following two conditions is met: 

• The respective slot counter reaches the maximum available Slot ID contained in cSlotlDMax, i.e. vSlotCounter_x 
> cSlotlDMax. 

• The start of the network Idle time is reached, i.e. vMacrotick = gtStartNIT. 
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Frame Validation 

[0151] Receive buffers are only updated in Normal Mode; receive buffers are not updated during startup. 
[0152] All of the following (channel individual) checks must be successful for a dynamic frame in a receiver before 
5 the frame may be copied into a receive buffer: 

Context and coding checlcs 

[0153] 

10 

• CheckldleBeforeFrame_x 

• CheckFrameCoding_x 
15 • CheckHeaderCRC_x 

• CheckCRC_x 

• CheckldleAfterFrame_x 

20 

Content checks 
[0154] 

25 • CheckFramelDDynamicRange_x 

• CheckCycleCount_x 

• CheckReceivedPayloadLength_x 

30 

Examples 

[0155] The examples given in the following sections are for a pure dynamic system. A mixed static/dynamic system 
would behave in a similar manner, except a constant value of gNumberOfStaticSlots wou\di be added to all slot counters 

35 and Frame ID's in Ihe examples. 

Examples of Fault-Free Situations 

[0156] The examples below show how a DCT or frame transmission/reception synchronizes the node's slot counters 

40 and how the slot counters are incremented during the wait time vdWaitTime. 

[0157] Figure 25 shows distributed synchronized slot counters of nodes A and B. Node A sends the ID's 2, 4 and 5. 
Node B sends the ID's 1 and 3. Figure 26 below demonstrates how the waiting time for the frame with Frame ID = 1 
Is calculated. At the end of the SOC (which in this case serves as the DCT) the waiting time begins. It consists of the 
fixed part pdWxORxandthe period pc/l/l/xDe/fafor the frame ID = 1 . As soon as the waiting time is over, the slot counters 

45 switch the value to 1 in all nodes - in this case, node B, since it has a transmit request for Frame ID 1 , starts transmitting. 
If a node recognizes a bus activity, e.g. because of a received frame, it stops its slot counter. In this way, the slot counter 
remains synchronized with the received or transmitted frame ID (Provided, of course, that the values for calculating 
the waiting time of the nodes are set correctly.). Bus activity detection is performed after the glitch filter. Bus activity is 
detected if at least one period of gdBit \s recognized as bus active (The 1 * gdBIt period of activity is equivalent to the 

50 minimum duration of the Frame Start Sequence). For a 2-State physical layer, bus activity equals the logical '0' level. 
For a 3-state physical layer, bus activity equals either a logical '0' or a logical '1' with the RX_enable signal active. 
[0158] Figure 26 shows the calculation of vdWaitTime after DCT. 

[0159] Figure 27 shows the waiting time {vdWaitTime) calculation between the frames that carry Frame ID = 1 and 

Frame ID = 4: 

55 [0160] All slot counters in transmit slot 1 have a value of 1 . At the end of the frame with frame ID = 1 the wait time 
starts. It consists of the fixed part pdWxORx and three times pdWxDelta waiting slots for the frame ID = 4. Each time 
one of the pdWxDelta times is over, the slot counters are incremented by one. Frame IDs 2 and 3 are now able to 
transmit. However, in this communication cycle no transmissions take place because there is no transmit request for 
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these two frames. After the waiting time for Frame ID = 4 is over, node B, which in this case has a transmit request for 

Frame iD 4, starts transmitting. 

[0161] To appiy the exampie to a mixed static/dynamic configuration it Is necessary to add the parameter gNum- 
berOfStaticSlots as an offset to ali siot counter and frame ID values. 

5 

Examples of Slot Counter Behavior in Case of Errors 

[0162] The following diagrams are intended to explain the waiting time calculation after frame format errors. They 
ail show the reception line (FiX) and the siot counter (referred to as slot) of a node. 
10 [0163] Figure 28 shows the slot counter after a frame format error, in particular an example of a CRC error detected 

in the last CRC byte on a 2-State physical layer. As soon as the ascending flani< and the bus Idle occurs at the receiving 
line the wait time vdWaitTime is started (at least hypothetically). Since activity is again detected on the bus before the 
slot counter is incremented, the wait time vdWaitTime is started again at the next ascending flank. In this case the time 
{pdWxORx+ pdWxDelta) elapses without any further bus activity and the slot counter Is Increased by one. Transmitting 

15 and receiving is now possible again starting with siot 5. 

[0164] Figure 29 shows an example of what happens when the receiving device Is able to detect an error some time 
after the last ascending f lani< of the error or of the frame fragment (slot counter after frame fragments). This is the case, 
for example, when using a optical physical layer with NRZ coding, if the receiving device expects the size of the frame 
(byteflight frame fonnat) to be larger than It actually Is because of a bit error In the data length field of the frame. The 

20 error can only be detected with the last missing stop bit, which Is 1 0 * gdBit after the last rising flank. The same effect 
occurs if a frame fragment that looks like a valid Frame Start Sequence Is detected on the receiving line. A format or 
coding error can only be discovered 1 0 * gdBit after the ascending flank because the frame fragment is accepted as 
a valid Frame Slarl Sequence and is only detected due to the missing stop bit. 

[0165] In all these cases, the waiting time vdWaitTime begins as soon as the error is detectable and the receive line 
25 has reached the bus Inactive state. 

[0166] The error handling methods described above are applied In pure dynamic configurations and during the dy- 
namic segment In a mixed static/dynamic configurations. 



Network Idle Time 

30 

[0167] The duration of the network Idle time is denoted gdNIT. 
[0168] The network Idle time starts at 
gtStartNIT= gdCycleTime - gdNIT 

[0169] The parameter grdMT depends on the signal propagation delay, the clock synchronization execution time, 
35 and an additional time period that ensures the ability of a node to properly handle the reception of a frame that starts 
up to 0,5 * pdS/of before the first siot of the cycle begins. 

[01 70] Any ongoing frame reception is aborted when the Network Idle Time begins. The incompletely received frame 
Is treated as an error (warning level) that is signaled to the host. 



40 Modes and Configuration 
FlexRay Pure Static iVIode 



[0171] in FlexRay pure static mode the communication cycle contains the static segment and the network Idle time. 
45 This mode is available In single and dual channel configurations. 



Cluster Specific Configuration 



[0172] At least 2 static communication slots must be configured. 

[0173] At least 2 synchronization frames must be exchanged. 

[0174] Comment: synchronization frames - Is not introduced, to be explained 

[0175] Comment: Crosscheck with clock sync chapter. A system should continue working even if only one Sync 
frame Is left.) What happens If two nodes are in operation and one node falls. Does this cause the remaining node to 
stop? 

Node Specific Configuration 



[0176] The following parameters must be configured: 
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• gNumberOfStatlcSlots (number of static slots) 

• gdSlot (the duration of one static siot) 

5 • gdCycle (the duration of the communication cycie) 

• gdNIT (the duration of the networi< idie time) 

• The configuration must satisfy gdCycle = {gNumberOfStaticSlots * gdSlot) + gdNIT 

10 

FlexRay Mixed Static/Dynamic Mode 

[0177] In FlexRay mixed static/dynamic mode the communication cycle contains the static segment, the dynamic 
segment and the networic idie time. 

15 

• This mode Is available in single and dual channel configurations. 

• Ail nodes execute the clock synchronization using the frames of the static segment. 

20 • it is possible to configure nodes that transmit frames only within the dynamic segment. These nodes have a static 
segment configured but have no transmit buffer configured to send frames with a Frame ID less than or equal to 
gNumberOfStaticSlots. 

• Nodes that transmit only during the dynamic segment tal<e part in the ciocl< synchronization by receiving sync 
25 frames and determine the start of the dynamic segment in the same way as nodes that also transmit frames In the 

static segment. 

• During the dynamic segment the frame sequence on the two channels is independent and may be different, i.e., 
any node may send different frames with different Frame ID's on the two channels, resulting in a different frame 

30 sequence on the two channels. 

• The length of frames transmitted in the dynamic segment may be different for every communication cycle. I.e., 
frames with the same Frame ID may have variable length. A frame's length Is derived from the payioad length field 
in the frame header. 

35 

• A frame is only transmitted during the dynamic segment if the corresponding transmit buffer was marked as "ready 
for transmission", i.e., no "nuli frame" will be sent if the host does not update the data. This is in contrast to the 
static segment, where the CC will send a null frame If a buffer is configured for a slot but the host does not mari< 
the buffer "ready for transmission". 

40 

• For a given communication cycie the dynamic segment may be empty, i.e., no frames are transmitted with dynamic 
medium access control. This may be because no frame with a frame ID greater than pNumberOfStaticSlots is 
configured in any transmit buffer, or because no dynamic segment frame has been marked "ready fortransmisslon" 
by its host, 

45 

• The startup mechanism for this mode is the same as for the pure static mode. 

• In this mode startup is only performed by coldstart nodes. 
50 Cluster Specific Configuration 

[0178] 

• At least 2 static communication slots must be configured. 

55 

• At least 2 synchronization frames must be exchanged. 
[0179] The following parameters must be configured: 
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• gNumberOfStatlcSlots (number of static slots) 

• gdSlot (the duration of one static siot) 

5 • gdCycle (the duration of the communication cycie) 

• gdNIT (the duration of the networi< idie time) 

• pdLatestTx (iatest starting point for a frame in the dynamic segment) 

10 

• The duration of the dynamic segment is caicuiated by: gdDynamicPart= gdCycle - gdNIT - {gNumberofStaticSlots 
* gdSlot). 

• The node must be configured in a way that the dynamic segment is active, i.e. gdDynamicPartmustbe long enough 
15 and the parameter pdLatestTx must be configured in a way so that it is possible to transmit at least one frame 

during dynamic segment. 

• The parameter pdLatestTx is be configured in IVIacroticks individual for each node in a way so that the longest 
frame to transmit by the node does not overlap with gdNIT. 

20 

• pdWxDelta must be configured. 
Node Specific Configuration 

25 [0180] 

• pdWxOTx 

• pdWxORx 

30 

FiexRay and bytefiight Pure Dynamic ItAode 
[0181] 

35 t This mode is available in single and dual channel configurations 

• In this mode startup and synchronization Is performed by means of the SOC symbol that serves as DCT. 

• The first received DCT starts the dynamic media access scheme on both channels at the same time. 

40 

• In this mode one node of the cluster is configured as SOC master by its host. 

• There are two different SOC symbols: SOC Normal and SOC Alarm. Referto the coding chapter for further details. 

45 » The SOC master generates SOC symbols at the beginning of each communication cycle. The duration of one 

cycle is configured by gdCycle. 

• After startup the SCO master generates SOC Normal symbols. 

50 • The SOC master may be switched to generate SOC Alarm symbols by the host. The SOC master switches back 
automatically to generating SOC Normal symbols after 1 023 * gdCycle. The host of the SOC master may trigger 
the generation of SOC Alarm symbols again before 1 023 * gdCycle is elapsed. In that case the SOC master restarts 
the timer to count the period of 1023 * gdCycle. The host may switch immediately from the generation of SOC 
Alarm symbols to the generation of SOC Normal symbols before the period of 1023 ' gdCycle is elapsed by ac- 

55 cessing the host interface. When switching from SOC Normal to SOC Alarm (or vice versa) the duration of one 

communication cycle remains gdCycle. 

• SOC Normal and SOC alarm symbols are treated identically with respect to media access. 
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• All non-SOC master nodes use the SOC symbol for synchronizing their local clock that determine media access 
during the cycle. Therefore no media access Is possible if there is no valid SOC present or if the last valid SOC 
was received more than gdCycle ago. 

5 • The frame sequence on the two channels is Independent and may be different, i.e., any node may send different 
frames with different Frame ID'S on the two channels, resulting in a different frame sequence on the two channels. 

• The length of frames transmitted in the dynamic segment may be different for every communication cycle, I.e., 
frames with the same Frame ID may have variable length. A frame's length Is derived from the payload length field 

10 in the frame header for FlexRay frames, and from the data length field In the header for bytef light frames. 

• A frame Is only transmitted during the dynamic segment if the corresponding transmit bufferwas marked as "ready 
for transmission", I.e., no "null frame" will be sent if the host does not update the data. 

15 » For a given communication cycle the dynamic segment may be empty, i.e., no frames are transmitted with dynamic 
medium access control. This may be because no frame has been mari<ed "ready for transmission" by its host. 

Cluster Specific Configuration 

20 [0182] 

• The number of static slots gNumberofStaticSlots, the parameters pdLatestTX and gdNIT and the duration of the 
communication cycle gdCycle must be configured. The duration of the dynamic segment is calculated by; vdDy- 

namicPart^ gdCycle - gdNIT - gdSOC. 

25 

• A node is In dynamic mode If the number of static slots gNumberofStaticSlots is configured equal zero. 

• The parameter pdLatestTx must be configured individual for each node In a way so that the longest frame to 
transmit by the node does not overlap with gdNIT. 

30 

• pdWxDelta must be configured. 

byteflight Mode Configuration 

35 [0183] In order to ensure compatibility with byteflight-specific hardware in byteflight compatibility mode the following 
parameter configuration must be chosen: 

• byteflight frame format 
40 . coding: NRZ8N1 

• physical layer: 2 state physical layer 

• gNumberofStaticSlots: 0 

45 

• gdBit. 1 00 ns 

• pdLafesfTxshould be configured so that It equals 231 \is 
50 • fifdW/T should be configured so that it equals 0 jis 

• gdCycle: 250 jis 

• gdCycleMIn: 249.725 (xs 

55 

• gdCycleMax. 250.275 p.s 

• gBitRater. 1 0 Mblt/s 
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• type of physical layer concerning wake-up method: optical byteflight 
Node Specific Configuration 

s [0184] 

• pdWxOTx 

• pdWxORx 

10 impiementation Notes 

[0185] Some physical layers generate echoes of signals transmitted by the communication controller which may be 
seen with a certain delay on the Rx Input of the communication controiler's receiver. For exampie, this may happen if 
a communication controiler is connected directiy to an eiectricai star without using a bus driver device or if the physical 
15 layer device features a ioop back function which causes a significant delay (at least 0.5 * gdBitj. In order to prevent 
the receiver from detecting noise and signaling this to the host, the Rx Pin should not be evaluated for that purpose 
during pdWxOTx after the transmission of a message or a SOC symbol has ended. 

Externai Trigger Itlode (optlonai for V5) 

20 

[0188] In dynamic configuration it is possible to start the communication cycle by means of an external trigger. 

• This mode is enabled/disabled by a configuration parameter. 
25 * This mode Is available in FlexRay mode and in byteflight mode. 

• The external trigger starts the communication cycle either 

• by a falling edge on an external trigger pin or 

30 

• by the host by writing to a dedicated trigger control bit. 

• The timing of the external trigger cycle is monitored through the two parameters pdCycleMin and pdCycleMax. 

35 » If the external trigger appears later than pdCycleMin and earlier than pdCycleMax (case 1): No Error is signaled 
and the SOC is triggered by the external trigger 

• If the external trigger does not appear before pdCycleMax (case 2): A SOCLIF (SOC Lost Interrupt Flag) Error is 
signaled and the SOC is triggered after pdCycleMax. 

40 

• If the external trigger appears earlier than pdCycleMin (case 3): A SOCEIF (SOC Early Interrupt Flag) Error is 
signaled and the SOC is triggered after pdCycleMin. 

[0187] Figure 30 shows an externally triggered SOC. 

45 

Comments 

[0188] Comment: Explain rules for calculating the values pdWxOTx, pdWxORx, pdWxDelta, ... in a extra subchapter 
(similar to byteflight spec) after simulation investigation with cascaded stars has been done. 
50 [0189] Comment: VdWaitTime calculation is based on uncorrected Microticks (V5). If a controller supports cor- 
rected microtlcks the parameter pdWxDelta could be minimized. 

[0190] Open Topic: OT96: semantic of receive window, Include figure showing receive windows. 
Chapter 5 

55 

Frame and Symbol Formats 

[0191] This chapter describes the supported frame, symbol, and packet formats used by the FlexRay protocol. The 
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first section focuses on the frame and symboi formats, the second section describes the packet format and the sub- 
sequent section describes the coding schemes. 

[0192] The reiationship between frame, pacl<et and encoded pacl<et is such that the frame is embedded in a pacl<et 
before it is coded for the physlcai layer. This separation decouples the frame format from the format required on the 
5 physical layer. This decoupling allows the FlexRay protocol to make use of different physical layers that require distinct 
coding methods. 

Frame and Symbol Formats 

Frame Formats 

[0193] The FlexRay protocol supports two distinct frame formats: 
the FlexRay frame format 

15 

the byteflight frame format 

[0194] All controllers In a cluster must be configured to use the same frame format. Specifically, a system In which 
some controllers use the FlexRay frame forniat while other controllers use the byteflight frame format is not a valid 
20 system configuration. 

[0195] The FlexRay frame format may be used for systems with pure static, pure dynamic, and mixed (static plus 
dynamic) media access methods. 

[0196] The byteflight frame format may only be used in systems operating in byteflight compatibility mode. 
[0197] Both frame formats contain a header segment, a payload segment and a trailer segment, each of which 
25 contains specific fields. 

[0198] These are described for the FlexRay and byteflight frame formats, respectively in Sections "FlexRay Frame 
Format" and "byteflight Frame Fonnat", and Illustrated, respectively. In Figure 31 and Figure 32. 

Symbol Formats 

30 

[0199] The FlexRay protocol makes use of four distinct symbols. These symbols exist outside of the normal frame/ 
packet formats. The FlexRay symbols are: 

Start-of-Cycle (SOC) symbol (two types) 

35 

SOC Normal Symbol 
SOC Alarm Symbol 
40 Wake-Up Symbol 

Collision Avoidance Symbol 
[0200] The symbol formats and their use are described in Section "Symbol Format". 

45 

FlexRay Frame Format 

[0201] An overview of the FlexRay frame format is given in Figure 31 . The frame shall be transmitted on the network 
such that the header segment appears first, followed by the payload segment, and then followed by the trailer segment, 

50 which is transmitted last. 

FlexRay Header Segment 

[0202] The FlexRay header segment consists of 5 bytes that contain several distinct fields; two fields of reserved 
55 bits, the Frame ID, a Payload Length field, a Sync Bit, a Header ORG field, a Data Update Bit, and a Cycle Counter 
field. These fields are described in detail in the following sections. 

[0203] Within the header segment the fields shall be transmitted In the order indicated In Figure 31 , moving from left 
to right (I.e., the Reserved 1 field Is transmitted first and the Cycle Counter field is transmitted last). 
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30 



40 



Reserved 1 (2 bits - fAcknowLength) 

[0204] This field consists of two reserved bits. In subsequent versions of the protocol these bits may be used to 
indicate the length of an optional acknowledgement vector contained within the payload segment of the frame. When 
used for this purpose, this field has the following meaning: 

fAcknowLength = (OOjg - no acknowledgement vector 
fAcknowLength = (01)3 - acknowledgement vector of 1 byte 
fAcknowLength = (1 0)3 - acknowledgement vector of 2 bytes 

fAcknowLength = (11 )2 - acknowledgement vector of 3 bytes 

[0205] The Reserved 1 field shall be transmitted such that most significant bit of fAcknowLength is transmitted first. 
[0206] Version 5 Solution: FPGA V5 does not support acknowledgement vectors. An FPGA V5 implementation 
shall transmit this field with fAcknowLength = (00)2. This is consistent with the lack of an acknowledgement vector 

Reserved 2 (2 bits - fReservedBits) 

[0207] This field consists of two bits that are reserved for future protocol use. These bits shall not be used by the 
application. 

The Reserved 2 field shall be transmitted with both bits set to logical '0'. As the bits are Identical, transmission 
order is not defined. 

Frame iD (12 bits - fFramelU) 

[0208] This field contains the Frame Identifier for the frame. Each frame that may be transmitted in a cluster has a 

frame ID /Frame/D assigned. 

[0209] The frame ID /Frame/D is a unique number per communication channel per communication cycle and defines 

the slot in which the frame is transmitted 

[021 0] Valid values for fFramelD range from (0000 0000 0001 )2 to (1 11 1 1111 1111)2. 

[0211] The Frame ID field shall be transmitted such that the most significant bit of fFramelD is transmitted first with 
the remaining bits of fFramelD being transmitted In decreasing order of significance. 

Payload Length (7 bits - fPayloadLength) 

[0212] The Payload Length field consists of a single parameter, fPayloadLength, that is related to the number of 
bytes contained in the payload segment of the frame. Specifically, fPayloadLength indicates the number of bytes in the 
payload segment divided by two. For example, a frame that contains a payload segment consisting of 72 bytes would 
be sent with fPayloadLength =ZQ. Refer to Section "FlexRay Payload Segment" for a detailed definition of the contents 
of the payload segment of a FlexRay frame. 

[021 3] The payload length field does not include the number of bytes within the header and the trailer segments of 
the FlexRay frame. 

[0214] The maximum payload length is cPayloadLengthMax, which corresponds to a payload segment containing 2 
* CPayloadLengthMax byles. The payload field shall be less than or equal to the maximum payload length: fPayhad- 
Length < cPayloadLengthh/lax. 

[0215] The payload length shall be fixed for all frames in the static segment of a communication cycle. For these 
frames the payload length field shall be transmitted with fPayloadLength = gPayloadLengthStatlc. 
[0216] The payload length fPayloadLength may be different for different frames in the dynamic segment of a com- 
munication cycle. In addition, the payload length of a specific dynamic segment frame may vary from cycle to cycle. 
Finally, the payload lengths of a specific dynamic segment frame may be different on each configured channel. All 
dynamic segment frames, however, shall have 0 < fPayloadLength < cPayloadLengthMax. 
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[0217] The Payload Length field shall be transmitted such that the most significant bit of fPay/oac/Lengrfrt is transmitted 
first with the remaining bits of fPayloadLength being transmitted in decreasing order of significance. 

Sync Bit (1 bit - fSyncBit) 

5 

[0218] The sync bit fSynce/f determines whether the frame is to be used for clock synchronization. 
[0219] The condition fSyncBit= 1 Is one of several conditions that must be true for the frame to be used for clock 
synchronization. If fSyncBit= 0 the frame can not be used for clock synchronization. For details see the clock synchro- 
nization chapter (TBD). 

10 [0220] All frames transmitted In the dynamic segment (If present) shall be sent with fSyncBit= 0. 

[0221] If a node transmits a given frame on more than one channel It shall set fSyncBitXo the same value on each 
channel. 

Header CRC (9 bits - fHeaderCRQ 

15 

[0222] The Header CRC field contains a Cyclic Redundancy Check code (CRC) computed over the Payload Length 
and Sync Bit fields of the frame. 

[0223] The CRC Is computed In the same manner on all configured channels. The CRC polynomial (This 9 bit CRC 
polynomial generates a code that has a minimum Hamming distance of 6 for codewords up to 17 bits In length. The 
20 codeword consists of the data to be protected and the CRC. This con'esponds to protection of a data field of up to 8 
bits In length. In this application, this CRC protects exactly 8 bits of data (7 bits payload length + 1 bit sync = 8 bits).) 
shall be 



2^ jf'+*' +jc' +x* +l = {x + \){x' +x' +x' +x^ +;c + l) 

[0224] The initialization vector of the header CRC shall be (1 A)^^^' 

[0225] With respect to the computation of fHeaderCRC, the Payload Length and Sync Bit fields shall be fed Into the 
30 CRC generator In network order, specifically the most significant bit of the Payload Length field shall be shifted In first, 
followed by subsequent bits of the Payload Length, and then the Sync Bit field. 

[0226] The Header CRC field shall be transmitted such that the most significant bit of fHeaderCRC Is transmitted 
first with the remaining bits of fHeaderCRC being transmitted In decreasing order of significance. 
[0227] CommentiAn example for CRC calculation should be given. 

35 

Data Update Bit (1 bit - fDataUpdateBit) 

[0228] The data update bit fDataUpdateBit Indicates whether the host has updated the data. 
If the data update bit Is set to fDataUpdateBit = 1 the data was updated by the host. 
40 If the data update bit Is set to fDataUpdateBit = 0 the data was not updated by the host. 

[0229] The behavior of the FlexRay controller with respectto the data update bit Is described In Section "Data Update 
Bit Handling". 

Cycle Counter (6 bits - fCycleCount^ 

45 

[0230] The Cycle Counter field indicates the transmitting node's view of the cycle counter vCyc/e at the time of frame 
transmission 

[0231] The Cycle Counter field shall be set to fCycleCount = vCycle before transmitting a frame. 
[0232] The Cycle Counter field shall be transmitted such that the most significant bit of fCycleCount Is transmitted 
50 first with the remaining bits of fCycleCourit being transmitted In decreasing order of significance. 

FiexRay Payioad Segment 

[0233] The FlexRay payload segment contains 0 to 246 bytes of data written by the host. 
55 [0234] Because of the limitations Imposed on the representation of the length of the payload segment by the Payload 
Length field (fPayloadLerigtIi) of the header segment, the FlexRay Payload Segment shall consist of an even number 

of bytes. 

[0235] The first two bytes of the FlexRay payload segment may optionally be used as a message ID field, allowing 
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receiving nodes to fiiter or steer data based on tine contents of this field, 

[0236] Future versions of tlie protocoi may utilize certain bytes of the payload segment to implement an aclcnowl- 
edgement vector used in a protocoi-ievei acknowledgement service. 
[0237] Open Topic: Acknowledgement mechanism needs to be defined. 
5 [0238] Version 5 Solution: FPGA V5 does not support an acknowledgement service at the protocol level. 

[0239] The individual bytes within the Payload Segment shall be transmitted such that the most significant bit of the 
byte is transmitted first with the remaining bits of the byte being transmitted in decreasing order of significance. 

FlexRay Trailer Segment 

10 

[0240] The FlexRay trailer segment contains a single field, a 24-bit CRC for the frame. 
Frame CRC (24 bits - fFrameCRC) 

'5 [0241] The Frame CRC field contains a Cyclic Redundancy Check code (CRC) computed over the Header and 
Payload segments of the frame. The computation includes all fields in these segments (This includes the header CRC, 
as well as any Communication Controller-generated "padding" bytes that may be included in the Payload segment.). 
[0242] The ORG is computed using the same generator polynomial on both channels. The CRC polynomial (This 24 
bit CRC polynomial generates a code that has a minimum Hamming distance of 6 for codewords up to 2048 bits in 

20 length. The codeword consists of all frame data and the CRC. This corresponds to protection of a frame (Header + 
Payload) of up to 2024 bits (253 bytes) in length. As defined, the maximum FlexRay frame (Header + Payload) is 5 + 
246 = 251 bytes in length.) shall be 

25 X +X + X + X + X + X + X ■i' X * X + X + X + X + X + X + X + I 

- (jt-n)'(x" -t-x' -(-x'-hx' +jr-t-l)(x" +x' -i-x* +x' +x* +x' +l) 

[0243] The generation process of the CRC differs slightly depending on which channel the frame is being transmitted 
30 (Different initialization vectors are defined to prevent a node from communicating if it has crossed channels, connection 
of a single channel node to the wrong channel, or shorted channels (both controller channels connected to the same 
physical channel) in an easy and inexpensive way.): 

a. The initialization vector of the CRC generator shall be (FE DC BA)hex foi" frames sent on channel A. 

35 

b. The initialization vector of the CRC generator shall be (AB CD EF)hex foi" frames sent on channel B. 

[0244] With respect to the computation of /FramerCflC, the framefields shall be fed into the CRC generator in network 
order (that is, the first thing into the generator is the most significant bit of the Reserved 1 field, and the last thing into 
'io the generator is the least significant bit of the last byte of the Payload Segment). 

[0245] The Frame CRC field shall be transmitted such that the most significant bit of fFrameCRC is transmitted first 
with the remaining bits of fFrameCRC being transmitted in decreasing order of significance. 
[0246] Comment: An example for CRC calculation should be given. 

45 byteflight Frame Format 

[0247] An overview of the byteflight frame format is given in Figure 32. The frame shall be transmitted on the network 
such that the header segment appears first, followed by the payload segment, and then followed by the trailer segment, 
which is transmitted last. 

50 

byteflight Header Segment 

[0248] The byteflight header segment consists of 2 bytes that contain several distinct fields; the Frame ID, a field of 
reserved bits, and the frame length. These fields are described in detail in the following sections. 
55 [0249] Within the header segment the fields shall be transmitted in the order indicated In Figure 32, moving from left 
to right (i.e., the Frame ID field is transmitted first and the Frame Length field is transmitted last). 
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Frame ID (8 bits - IBIFrameHJ) 

[0250] This field contains tlie Frame Identifier for tine frame. Each frame that may be transmitted in a cluster has a 
frame iD fS/Frame/D assigned. 
5 [0251] The frame iD fBfFramelD \s a unique number per communication channel per communication cycle and de- 
fines the minislot in which the frame is transmitted Valid values for fBfFramelD range from (0000 0001 )2 to (1 1 1 1 1 1 1 1 )2. 
[0252] The Frame ID field shall be transmitted such that the most significant bit of fBfFramelD Is transmitted first with 
the remaining bits of fBfFramelD being transmitted In decreasing order of significance. 

10 Reserved Bits (4 bits - fBfReservetlBits) 

[0253] This field consists of four bits that are reserved for future protocol use. These bits shall not be used by the 

application. 

[0254] The Reserved Bits field shall be transmitted with all bits set to logical '0'. As the bits are identical, transmission 

15 order is not defined. 

Frame Lengtli (4 bits - fSfFrameLength) 

[0255] The Frame Length consists of a single parameter, fBfFrameLengtfi, that Indicates the number of data bytes 
20 that are contained in the payload segment of the frame. 

[0256] The frame length field does not Include the number of bytes within the header and the trailer segment of the 

byteflight frame. 

[0257] The shortest possible length is 0 bytes ( fSfFrameLength - (0000)2 )< longest length Is 12 bytes (fBfFrame- 
Length = (1100)2 )■ ^ frame which is received with fBfFrameLength greater than 12 shall be treated as an error. 
25 [0258] The Frame Length field shall be transmitted such that the most significant bit of fSfFrameLength \slransrr\Kle6 
first with the remaining bits of fSfFrameLength being transmitted In decreasing order of significance. 

byteflight Payioad Segment 

30 [0259] The byteflight payload segment consists of 0 to 1 2 bytes of data written by the host. 

[0260] The Individual bytes within the Payload Segment shall be transmitted such that the most significant bit of the 
byte Is transmitted first with the remaining bits of the byte being transmitted In decreasing order of significance. 

byteflight Trailer Segment 

35 

[0261] The byteflight trailer segment consists of 2 bytes that contain two distinct fields; a Frame CRC and the Frame 
Completion Bit. These fields are described in detail in the following sections, 

[0262] Within the trailer segment the fields shall be transmitted in the order indicated in Figure 32, moving from left 
to right (i.e., the Frame CRC field is transmitted first and the Frame Completion Bit Is transmitted last). 

40 

Frame CRC (15 bits - fBfFrameCRQ 

[0263] The Frame CRC field contains a Cyclic Redundancy Check code (CRC) computed over the Header and 
Payload segments of the frame. The computation Includes all fields In these segments. 
45 [0264] The CRC generator polynomial (This is the same polynomial as used in the CAN protocol as defined in in- 
ternational Standards Organization (1993). Road Vehicles - Interchange of Digital Information - Controller Area Network 
(CAN) for High Speed Communication. IS011898, 1993. It Is optimized for code words of up to 127 bits.) shall be 

15 14 10 8 7 4 3 J 
50 X+X+X+X+X+X+X+1 

[0265] The Initialization vector of the byteflight Frame ORG shall be (OO)Hex- 

[0266] With respect to the computation of fBfFramerCRC, the frame fields shall be fed Into the CRC generator In 
network order (that Is, the first thing Into the generator Is the most significant bit of the Frame ID field, and the last thing 
55 into the generator Is the least significant bit of the last byte of the Payload Segment) 

[0267] The Frame CRC field shall be transmitted such that the most significant bit of fSfFrameCRC Is transmitted 
first with the remaining bits of fSfFrameCRC being transmitted In decreasing order of significance. 
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Frame Completion Bit (1 bit - fBfFCB) 

[0268] The Frame Completion Bit, fBfFCB, is a single bit whose sole purpose is to allow the byteflight frame to end 

on a byte boundary. 

5 [0269] The Frame Completion Bit field shall be transmitted with fBfFCB^ 0. 

[0270] Open Topic: Is the 11 -bit bus idle necessary for end-of-frame detection? (movethis to the validation checks 
In general as this applies for FlexRay format) 

Symboi Format 

10 

[0271] The FlexRay protocol makes use of four distinct symbols. The FlexRay symbols are: 
Start-of-Cycle (SOC) symbol (two types) 
15 see Normal Symbol 

SOC Alarm Symbol 
Wake-Up Symbol 

20 

Collision Avoidance Symbol 
[0272] The following sections describe the symbols and their use. 
25 SOC Symbois 

[0273] The FlexRay protocol makes use of two distinct Start-of-Cycle symbol (SOC) symbols, an SOC Nonnal symbol 
and an SOC Alarm symbol. These symbols have the following definition: 

30 a. A SOC Nonnal symbol is defined as a sequence of 30 logical O's 

b. A SOC Alarm symbol Is defined as the sequence of 10 logical I's followed by 20 logical O's. 

[0274] Note: The SOC Normal and SOC Alarm symbols have the same duration [30*gdBif), and both symbols start 

at the same point in time relative the beginning of a normal communication frame. 
35 [0275] Comment: How lo detect the start of such a symbol? --> tolerances must be increased 

[0276] The SOC Normal symbol is used in systems operating in the byteflight compatibility mode or in the FlexRay 
pure dynamic mode. The SOC Alarm symbol is only used in systems operating in the byteflight compatibility mode, 
[0277] The conditions under which these symbols are transmitted are described in the chapter "Media Access 
Scheme". 

40 

Collision Avoidance Symboi 

[0278] The Collision Avoidance Symbol (CAS) Is used to minimize the possibility of collisions during the startup 
phase of FlexRay systems which feature a static segment (i.e., systems operating in the pure static or mixed static 

45 operating modes). Refer to the chapter "Startup" for further information. 

[0279] The Collision Avoidance Symbol shall have the same definition as the SOC Normal described in Section "SOC 
Symbols". 

[0280] The Collision Avoidance Symbol is sent once during cold start before the first communication cycle in pure 
static or mixed static-dynamic FlexRay mode (for details see the "Start-up" and "Media Access Scheme" chapters). 
50 [0281] The Collision Avoidance Symbol shall not be used in systems operating in the FlexRay pure dynamic or 
byteflight compatibility modes. 

Walce-up Symbol 

55 [0282] The Wake-up symbol Is used to allow a node to transition from a low power consumption standby state to a 
state in which it is able to communicate (i.e., to "wake up") based solely on signals received on the communications 
link(s). Differences in the physical characteristics of the physical layers cause the existence of two distinct Wake-up 
symbols, one for the electrical physical layer and one for the optical physical layer 
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Electrical Wake-up Symbol (not for V5) 
[0283] Open Topic: Description for wai<e-up symbol 
5 Optical Wake-up Symbol 

[0284] 6,4^s iow; 6,4^s iiigii over 10ms (10 MBit/s data rate) ~> is described in sleep and wai<e-up ciiapter. 
Dependencies 

10 

Host Interface Requirements 
Header CRC Calculation 

'5 [0285] Among its other uses, the Header CRC field of a FlexRay frame is intended to provide protection against 
improper modification of the Sync Bit field by a faulty communication controller (CO). The CO that is responsible for 
transmitting a particularframeshail not compute the Header CRC fieldforthatframe. Rather, the CC shall be configured 
with the appropriate iHeader CRC for a given frame by the host. This mai<es it uniii<eiy that a fault in the CC that causes 
the value of a Sync Bit to change would result in a frame that is accepted by other nodes in the networi< because the 

20 CRC would not match. This Is possible because, for fixed length frames at least, the Header CRC would be constant. 
Removing the capability of the transmitter to generate the CRC minimizes the possibility that a CC fault would have a 
proper header CRC. 

[0286] The CC lhal is responsible for the reception of a frame shall perform the CRC computations required to checi< 
the correctness of the Header CRC field relative to the other information that is received in the frame. 

25 

Data Update Bit Handling 

[0287] The Data Update Bit shall be set to fDatailpdateBit = 0 during soft reset. 

[0288] The Data Update Bit shall be set to fDataUpdateBit= 1 by the host when it updates a transmit message buffer. 
30 (Note - the host would set this bit even if the data has not actually changed. This bit may be though of as a representation 
by the host that the data that is transmitted within the frame Is "fresh" and usable by the receiver. This bit does not 
represent a "data changed" condition within the host.) 

[0289] The Data Update Bit shall be set to /Dafal/pc/afe8/f= Oby the FlexRay controller after the transmission process 
has started. (The mechanism used shall be such that the value transmitted on the datalini< represents the value of the 
35 field at the time of the start of the transmission) 

[0290] The value of fDataUpdateBit'm the message buffer is transmitted in every frame as it is stored in the message 

buffer. 

Message ID (optional, 16 bits - fMessageIC) not relevant for V5 

40 

[0291] The first two bytes of the payioad segment of the FlexRay frame fonnat are receiver filterable data called 
IVIessage ID. 

[0292] The Message ID Is an application detenninabie number that describes the contents of the data segment. 
[0293] The Message ID is 16 bits long. 

45 [0294] The Message ID must be consistent in the whole cluster 

[0295] If this mechanism is used, the most significant bit of tMessagel D shaW be placed in the most significant bit of 
the first byte of the payioad segment. Subsequent bits of /Message/D shall be placed in the next payload bits in order 

of decreasing significance. 

[0296] Version 5 Solution: FPGA V5 does not support Message iD's. All bytes in the Payioad segment of a FlexRay 
50 frame shall be treated as normal host-generated data bytes by both receiving and transmitting nodes. 

Acknowledgement Vector (optional, 0/8/16/24 bits - fAcknowVectoi) not relevant for V5 

[0297] The third, fourth and fifth byte of the payioad segment may be used as for acknowledgement information. 
55 [0298] These bytes may be used for acknowledgement information. 

[0299] The Acknowledgement Vectorfield shall be transmitted such that the most significant bit of fAcknowVectoris 
transmitted first with the remaining bits of fAcknowVector be'mg transmitted in decreasing order of significance. 
[0300] Version 5 Solution: FPGA V5 does not support an Acknowledgement Vector. All bytes in the Payioad seg- 
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ment of a FlexRay frame shall be treated as normal host-generated data bytes by both receiving and transmitting 
nodes. (Note that this is the same behavior that would be implied for a FlexRay system that does support acl<nowl- 
edgement vectors in the case that the frame is indicated as having no acknowledgement vector (fAcknowLength = 
(00)2). This is the FPGA V5 required value for that field.) 

5 

Error Handling 

[0301] Comment: What happens when the data update bit fDataUpdateBit is set 0 In the dynamic part? -> It Is an 
errorl (may be map this error with another error) -> add in the check table. 

10 

Chapter 6 
Coding 

15 [0302] This chapter describes the coding methods used by the FlexRay system. 

[0303] Comment: The only coding method currently described Is the NRZ 8N1 method. Other coding methods, If 
adopted as part of the FlexRay system, will be added after they are approved. 
[0304] Version 5 Soiutlon: FPGA V5 only supports NRZ 8N1 coding. 

20 Coding with NRZ 8N1 

[0305] This section describes the FlexRay coding method referred to as NRZ 8N1 . The mechanism is given this 
name because it uses a Non-Return to Zero (NRZ) signaling method that uses symbols consisting of 8 data bits, no 

parity bits, and 1 stop bit (8N1). 

25 

Frame Packaging 

[0306] This section describes the frame packaging. Packaging adds physical layer specific elements to frames. The 
additional infonnatlon for NRZ 8N1 consists of the Frame Start Sequence (FSS). 

30 

Frame Start Sequence (FSS) 

[0307] The transmission of each frame shall begin with a Frame Start Sequence (FSS) consisting of 8 consecutive 

bits sent as logical "0". The FSS shall be transmitted without any start or stop bits, 
35 [0308] Version 5 Solution: This definition of the FSS is valid for FPGA V5 only, it may change for future versions 
of the protocol. 

[0309] Due to certain effects on the physical transmission medium (e.g., optical transmission, truncation due to con- 
nection setup in the star coupler, etc.), it is possible that the FSS seen by a receiver may be shorter or even longer 
than the FSS that was sent by the transmitter. All receivers shall accept Frame Start Sequences with a duration of 1 -9 
40 bit times. 

Symbol (SOC) Packaging 

[0310] No additional infonnation is needed for symbol packaging, i.e., the symbols shall be transmitted without any 
45 start and stop bits. 

Frame Coding 

[0311] Figure 33 shows the frame coding when using NRZ 8N1 . 
50 [0312] The frame is composed of a Frame Start Sequence and an integral number of byte frames, each of which 
convey 8 bits of higher layer data. 

Byte Coding 

55 [0313] 

• Byte frames within aframe shall be sent without idle phases In between, i.e., there Is no interruption of the bit stream. 
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• Each byte frame shall begin with one start bit (iogicai "1"), foiiowed by 8 data bits and one stop bit (logical "0"). 

There Is no parity bit. 

• Transmission of the data bits within a byte frame shali be such that the most significant bit of the data Is transmitted 
5 first with the remaining bits of the data being transmitted in decreasing order of significance. This is shown in Figure 

34. 

Symbol Coding 

10 [0314] The NRZ 8N1 coding mechanism defines three distinct symbols; two different Start of Cycie (SOC) symbois, 
SOC Normai and SOC Aiann, and a Coiilslon Avoidance Symbol (CAS). The coding of these symbois is described in 
the foilowing sections. 

SOC Normal Symbol 

15 

[0315] The SOC Normal symbol shall be transmitted as 10 gdS/f times at a iogicai "1" ievei foiiowed by 30 gdBit 
times at a logical "0" ievei as is shown In Figure 35. 

[0316] The receivers of an SOC Normai signai shaii toierate the foliowing variations from the nominai definition of 
the signai: 

20 

• Due to certain effects on the physicai transmission medium (e.g opticai transmission, truncation due to connection 
setup In the star coupler, etc.), It is possibie for the 1 0 pd6;f times of iogicai "1 " sent by the transmitter to appear 
to be shorter al: the receiver. Therefore, ail receivers shail accept an SOC Nomiai symboi starting with a period of 
0-10 gofS/ftlmes at logical "1", 

25 

• The duration of the 30 pofS/f time at logical "0" may vary by + 1 .5 * gdBit, i.e., all receivers shall accept an SOC 
Normal symbol with a range of 28.5 to 31 .5 gdBit t\mes at logical "0" . 

[0317] Version 5 Solution: The preceding definition of the acceptance criteria of an SOC Nonnal symbol applies to 
30 the FPGA V5 implementation only. A different definition may be used in future versions of the protocol. 

[0318] The SOC Normal symbol Is used In pure dynamic configurations for synchronization. The SOC Normal symbol 
is sent by a single configured master. 

[0319] Note that the SOC Normal symbol is coded with neither start nor stop bits. (Rationale: This is an intentional 
code violation of the NRZ 8N1 frame coding rules). 

35 

SOC Alarm Symbol 

[0320] The SOC Alarm symbol shall be transmitted as 20 flfdS/f times at a logical "1 " level followed by 20 grdS/f times 
at a logical "0" level as is shown in Figure 36. 
40 [0321] The receivers of an SOC Aiann signal shall tolerate the following variations from the nominal definition of the 
signal: 

• Due to certain effects on the physical transmission medium (e.g., optical transmission, truncation due to connection 
setup In the star coupler, etc.). It is possible for the 20 pt/S/f times of logical "1 " sent by the transmitter to appear 

45 to be shorter at the receiver. Therefore, all receivers shall accept an SOC Alarm symbol starting with a period of 

10-20 pde/f times at logical "1". 

• The duration of the 20 gofSrt times at logical "0" may vary by + 1 .5 * gdBit, i.e., all receivers shall accept an SOC 
Alarm symbol with a range of 18.5 to 21 .5 gdBitlimes at logical "0". 

50 

[0322] Version 5 Solution: The preceding definition of the acceptance criteria of an SOC Alarm symbol applies to 
the FPGA V5 implementation only. A different definition may be used in future versions of the protocol. 
[0323] The SOC Aiann symbol is used In pure dynamic configurations for synchronization (same functionality as 
SOC Normal). The SOC Alarm signal Is sent by a single configured master (the same master that sends the SOC 
55 Normal signal). The SOC Alarm symbol can be used to Indicate a different operation mode. 

[0324] Note that the SOC Alarm symbol Is coded neither with start bits nor with stop bits. (Rationale: This is an 
Intentional code violation of the NRZ 8N1 coding rules). 



61 



5/19/2010, EAST Version: 2.4.1.1 



EP 1 355 456 A1 



Collision Avoidance Symbol (CAS) 

[0325] For NRZ 8N1 coding, the Collision Avoidance Symbol (CAS) shall be encoded in the same manner as the 
SOC Normal symbol described in Section "SOC Normal Symbol". 
5 [0326] Transmitters of the CAS have the same coding requirements as transmitters of the SOC Normal symbol. 
[0327] Receivers of the CAS have the same tolerance requirements as receivers of the SOC Normal signal. 
[0328] The Collision Avoidance Symbol is used at startup in pure static and mixed static/dynamic configurations for 
collision avoidance (see "Startup" chapter for further details). 

10 Bit Timing Toierances 

[0329] Clock oscillator differences and distortion on the transmission line may distort the timing of edges of received 
signals. As a result, the receiver of signals must accept signals with the following tolerances: 

15 t Thetoleranceof the bit timing is determined by the quality of the oscillators. Nodes shall tolerate osclllatorfrequency 
differences of up to + 1500 PPM (Parts Per Million). 

• A receiver shall tolerate deviations of + 35% concerning the parameter gdBit, i.e., single bit edges must be detected 
even if they are up to ± 0.35 * gdBitt\rr\es earlier or later than expected. 

20 

[0330] Version 5 Soiution: In FPGA V5 the sample voting mechanism (see Section "Edge Detection") can be con- 
figured to achieve the tolerances mentioned above. No additional mechanism Is required to support bit timing tolerances 
in V5. 

25 Giitcli Fiitering and Sampie Vbting 

[0331] Version 5 Soiution: The following requirements on glitch fiitering and sample voting apply to FPGA V5 only. 
Future protocol versions may use a different filtering/voting mechanism. 

[0332] The block diagram in Figure 37 shows the control flow of the receive and receive-enable signals through the 
30 glitch filter and sample voting mechanism. 

[0333] The following input and output signals are involved in the glitch filtering and sample voting mechanism. 



Table 9: 



Input and Output Signals for Glitch Filtering and 


RXDA 


Receive signal on FlexRay channel A 


RXDB 


Receive signal on FlexRay channel B 


RXEA 


Receive enable signal on FlexRay channel A 


RXEB 


Receive enable signal on FlexRay channel B 


RXDA_F 


Glitch filtered version of RXDA 


RXDB_F 


Glitch filtered version of RXDB 


RXEA_F 


Glitch filtered version of RXEA 


RXEB_F 


Glitch filtered version of RXEB 


RXDA_V 


Result of sample voting on RXDA_F 


RXDB_V 


Result of sample voting on RXDB_F 



50 

Sample Voting 
Giitch Fiitering 

55 [0334] Glitch filtering is performed on the receive signals of all configured channels (RXDA and/or RXDB) and on 
the receive enable signals of all configured channels (RXEA and/or RXEB). 
[0335] Glitch filtering shall be performed by the following mechanism: 
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• A number of samples pGI itch Sam pies is configured that determines the giitch iength to be filtered out by the glitch 
filter (see Figure 38). A configuration of pGlitchSamples = 0 means that no glitches are filtered out. 

• All pulses with a duration shorter than pGlitchSamples * pSamplePeriod shaW be filtered out. That means that the 
5 output of the glitch filter shall only change its logical value if more than pGlitchSamples equal samples are detected 

at the glitch filter's input (see Figure 38). Figure 39 and Figure 40 show examples of glitches that are filtered out 
by the glitch filter mechanism. 

Edge Detection 

10 

[0336] The edge detection process shall be performed on the glitch filtered version of the receive and receive-enable 
signals (RXDA_F RXDB_F RXEA_F RXEB_F). 

[0337] Edge detection is used for resynchronizing the bit sampling and voting process at the rising edge that results 
from the stop bit to start bit transition at the end of a byte. The edge detection process is also used to determine the 
15 end of an SOC or Collision Avoidance Symbol, and to detect the end of a frame in the dynamic part in order to start 
the slot counter mechanism. 

Sample Voting 

20 [0338] The sample voting process shall be performed on the glitch filter output of the receive signals (RXDA_F and/ 
or RXDB_F). 

[0339] The sample voting process defines a "window" of samples that are used to make the determination of the 

value of a received bit. This window is characterized by two parameters, pVotingOffset and pVotingSampies. An ex- 
ample showing the relationship of these two parameters is shown in Figure 41 . 
25 [0340] The parameter pVof/ngfOffsef specifies the offset of the start of the voting windowfrom the start of the bit cell. 
This offset defines the first sample of the bit that will be considered for the voting. 

[0341] The pVof/ngSamp/es parameter specifies the number of samples in the voting window. The window is defined 
by tal<ing pVotingSampies consecutWe samples starting with the sample indicated by pVotingOffset. 
[0342] The bit value shall be determined by majority voting over the samples within the voting window (This implies 
30 that the number of samples within the voting window, pVotingSampies, must be odd.), i.e., if a majority of samples 
within the voting window have logical value "0", the output value of the sampled bit shall be "0"; If a majority of samples 
within the voting window have logical value "1 " the output value of the sampled bit shall be "1 ". 
[0343] The voting window and the bit sampling shall be resynchronized with every start bit. 

35 Bit Rates and Sampling 

[0344] Version 5 Solution: The configuration parameters in this section (indexes, clock period, bit rates, etc.) only 
apply to FGPA V5. These requirements will be modified in future versions of this specification, 
[0345] FPGA V5 uses an 80 Mhz oscillator with a 12.5 ns oscillator period. FPGA V5 shall support the bit rates, 
40 prescalers, and sampling configurations defined in the following table. 



45 



50 



Index 


Sample Clock 


Sample Clock Period 


Samples per 


Bit Time 


Bit Rate 




Prescaler 


(ns) 


Bit 


(ns) 


(Mbps) 


1 


1 


12.5 


8 


100 


10.000 


2 


1 


12.5 


10 


125 


8.000 


3 


2 


25.0 


8 


200 


5.000 


4 


2 


25.0 


10 


250 


4.000 


5 


4 


50.0 


8 


400 


2.500 


6 


4 


50.0 


10 


500 


2.000 


7 


8 


100.0 


8 


800 


1.250 


8 


8 


100.0 


10 


1000 


1 .000 


9 


16 


200.0 


8 


1600 


0.625 


10 


16 


200.0 


10 


2000 


0.500 
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System Constants, Parameters and Variables 


Name 


Description 


RangeA^alue 


Unit 


pSamplePeriod 


Time interval between two consecutive sampling points 




ns 


pGlitchS3mplGs 


NumbGr of samplss thst sirs filt6r6d out by th6 9!'^^^ filtsr 
mechanism 


\\j-p^alTipiBSrerOll /^J 




pSamplesPerBit 


Number of samples per bit 


8 or 10 (V5 solution) 




pVotingOffset 


Defines ttie first sampie that is considered for the voting 
mechanism based on the glitch filter output 


[0-pSamplesPerBit ] 




p VotingSamples 


Defines the number of samples that are considered for the 
voting mechanism based on the glitch filter output 


1, 3, 5, 7, or 9 





15 

V6 Topics 
Frame packaging 

20 [0346] Open Topic: For V5 NRZ8N1 is used only. For the final silicon the decision about the coding is still open 
(NRZ 8N1 , Xerxes or another coding). Decision should be made before the middle of April 2002 (before the FlexRay 
workshop). One common coding scheme is preferred by all partners. 

Glitcli Filter 

25 

[0347] Open Topic: Analyze mechanism in a noisy environment. With configuration of a large pGlitchSamples (e. 
g., pGlitchSamples=5) a signal that is interrupted by several short glitches (within intervals shorter that 5) might lead 
to a rejection of the signal. Proposal: Use an up-down counter (integrator) that changes the detected value when the 
number of glitch samples is reached. 

30 

Chapter 7 

Ctock Synchronization 
35 Introduction 

[0348] In a distributed communication system every node has its own clock. Because of temperature and voltage 
changes and because of production tolerances of the timing source (normally quartz crystals arc used) the internal 
time base diverges between the nodes after a short time, even if all internal time bases of the nodes are started 
40 concurrently. 

[0349] The basis for a time triggered system is that, within tolerances, every node in the cluster has the same view 
of time and this common global view of time is used as the local time base for each node. In this context, "the same" 
means that the differences between the nodes' views of the global time are bounded and that a maximum value for 
this difference can be guaranteed. 

45 [0350] To guarantee a bound on the time differences between these nodes, clock synchronization is necessary. 
[0351] Two types of time differences between nodes can be distinguished, offset (phase) differences and rate (fre- 
quency) differences. To synchronize the local time base between nodes, methods are known for offset correction and 
for rate correction. In FlexRay a combination of both is used. 

50 Clock Synchronization Modes 

[0352] FlexRay supports two methods for synchronization of the local time base. Which synchronization method is 
used depends on the configuration (see Figure 42). Figure 42 shows the relation between the operation mode, media 
access and clock synchronization. 

55 
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Single-Master Clock Synchronization 
[0353] 

5 • If no static segment is configured for tine cluster {gNumberOfStaticSlots = 0) the communication cycle timing is 
based on tine Start-Of-Cycle (SOC) symbol. No distributed clock synchronization is performed. 

• The cycle length gMacroPerCycle is configured and measured in nominal (uncorrected) macroticks. 

10 * The cycle starts with the beginning of the SOC and ends with the beginning of the next SOC (see Figure 43). If 
no SOC is received (due to a fault) the macrotick counter should be incremented until it reaches its maximum 
value. No further incrementing is done. 

• A single master provides the SOC. If the master fails, a backup master can take over the task of transmitting the 
15 SOC if another host Intervenes to configure its communication controller to do so. There is no automatic protocol 

mechanism that will cause a new master to be established. 

• When a slave recognizes the reception of a valid SOC, it sets its local clock to cyclestart+ gdSOC. The gdSOC is 
configured during soft reset and quantifies the duration of the SOC, Including the time for recognition and checking 

20 of its correctness. The time in a slave runs from the predefined constant value gdSOCto gMacroPerCycle + gdSOC. 

Distributed Cioci< Synclironization 

[0354] Distributed clock synchronization is only performed if the cluster is configured with a static segment (gNum- 
25 berOfStaticSlots> 1). Thetime representation and the principles of the distributed clock synchronization are described 
In the Sections "Time Representation" through Section "External Clock Synchronization". 

Time Representation 

30 Local Time Representation in a Node 

[0355] 

• Internally, nodes can time their behavior with microtick resolution. Microticks are time units derived from the (ex- 
35 ternal) oscillator clock tick, optionally using a prescaler. Microticks are controller-specific units. They may have 

different durations in different controllers. The precision of a node's local time difference measurements is a mi- 
crotick. 

• Local controller time is based on cluster-wide synchronized cycle and macrotick values provided by the distributed 
40 clock synchronization mechanism. Finer resolution local timing is done using the node-specific microtick. 

• vCycle is the (controller-local) cycle number and is increased once every communication round. At any given time 
all nodes should have the same value for vCycle (except due to imperfect synchronization at cycle boundaries. 

45 • Cycle counter values {vCycle) range from zero (00 0000)2 1° cCycleMax (11 1 1 1 1 )2. 

• The maximum cycle counter value is configurable for a given cluster (gCycleMax). The first time the cycle counter 
{vCycle) is incremented after gCycleMax is reached, it is reset to zero. 

50 » gCycleMax must be less than or equal to cCycleMax. 

• gCycleMaxmust be an odd number (see Procedure 2). 

• vMacrotick is the current value of the (controller-local) macrotick counter. 

55 

• gMacroPerCycle defines the (integer) number of macroticks per cycle (see Figure 44). 

• Within tolerances, the duration of a macrotick is constant throughout the cluster on synchronized nodes. 
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30 



• Every node in the system has its own iocai view of the giobai time. The iocai view of global time is represented by 
a vector consisting of the current cycle number (vCycle) and the current macrotick value (vMacrotick). The value 
vCycle.vMacrotick is the (controller-local view of the) global time in the cluster. It is visible to the application. 

• pMicroPerMacroNom is the (controller-specific) nominal number of microticks per macrotick. 

• vMicroOverheadPerCycle is the (integer) number of microticks that has to be added to the pMicroperMacroNom 
' gMacroPerCycle microticks in the current cycle to produce the correct cycle length. vMicroOverheadPerCycle 
may be negative. The value of vMicroOverheadPerCycle is determined by the clock synchronization algorithm. It 
may only change once (usually at the beginning) per cycle. 

• pMicroOverheadPerCycleNom is the initial configuration value of vMicroOverheadPerCycle. 

• The duration of the current controller-local macrotick Is an Integer multiple of controller-local microticks and is 
represented by vMicroPerMacroCorr. The value of vMicroPerMacroCorr within one controller may change from 
macrotick to macrotick. 

• In any given cycle, vMicroOverheadPerCyclem]cro\.\cks must be distributed across the firMacrofterCyc/emacroticks 
comprising the cycle in order to adjust the cycle length to the proper duration. Consequently, vMicroPerMacroCorr 
does not remain constant. In general, vMicroOverheadPerCycle\s nonzero and is not a multiple of g/WacroPerCyc/e. 
Consequently, the process of distributing the vMicroOverheadPerCycle microticks across the gMacroPerCycle 
macroticks conceptually introduces fractional macraticks. 

• At the beginning of the first communication cycle the "local time variables" are initialized (see Procedure 1 ). 
Procedure 1: Initialization of anode 

[0356] 

[vCycle, vMacrotick, vMicrotick, vMicroPerMacroCorr] = 
Nodelnitialization () // 

vCycle = 0; //reset cycle 

counter 

vMacrotick = 0; //reset 
macrotick counter 

vMicrctick = 0; //reset 
microtick counter 

VMicroPerMacroCorr = pMicroPerMacroNom; //set the 

predefined value 
for 

VMicroOverheadPerCycle = pMicroOverheadPerCycleNom 
//itiicroticks per macrotick 

• The initialization of the first three values differs if the node reintegrates into a running cluster (see TBD section 
Startup and Reintegration). 
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Procedure 2: Incremerttlng the Cycle Count 
[0357] 

5 

[vMacrotick, vCycle] = ChangeOf CycleCount ( vMacroticJc, vCycle) 
// 

if vMacrotick >= gMacroPerCycle // 

vCycle++; //increment cycle 

counter 

vAfacroticic = 0; //reset 
macrotick counter 

15 

if vCycle > gCycleMax // 

vCycle = 0; //reset cycle 

counter 

20 end ; / / 

end; // 

• The host is able to read the cycle counter and the macrotick counter. The update of the cycle counter and the 
25 macrotick counter has to be atomic. 

• The duration of a Macrotick is a whole number of a Microticks, however, the number of microticks per macrotick 
may differ from macrotick to macrotick. Before the first correction value is calculated the clock synchronization 
algorithm works with nominal macrotlcks, using vMiaroPerMacroCon - pMicroPerMacroNom + pMicroOverhead- 

30 PerCycleNom (see 0). 

• The number of microticks per nominal macrotick may differ between nodes and depends on the oscillatorfrequency 
and the prescaler. 

35 » The duration of one cycle is a whole number of a macroticks. The number of macrotlcks per cycle is identical in 
all nodes In a cluster (see Figure 44). 
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Procedure 3: Incrementing the Macrotick Counter 
[0358] 

[vMicrotick, vMacrotick] = 

IncrementMacrotickCounter {vMicroPerMacroCorr, vMicrotick, 
vMacrotick) 

//uses microtick 

pulses 

while (1) // 

wait {Microtick_duration) ; //every 

microtick increase 

vMicrotick++: //microtick 

counter by one 

if vMicrotick >= vMicroPerMacroCorr // 



vMicrotick = 0; //Reset 
microtick counter 

vMacrotick++; //Increment 
macrotick counter 

end; // 
end; // 



• For a given cycle (without offset correction) tlie average iengtfi of a macroticit is given by pMicroPerMacroNom + 
vMicroOverheadPerCycle I gMacroPerCycle. 

Procedure 4: Uniform Distribution olMicroticks 

[0359] Comment: Thefoiiowingexampie only addresses the distribution of microticl<soverthemacrotici<s comprising 
the cycie. The more complete solution must also deal with offset corrections and is described in 0 
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initRateStartOf Cycle (vMicroOverheadPerCycie) 
//execute at beginning of cycle 

//sufficient every 

second cycle 

vMicroPerCycle = gMacroPerCycle * pMicroPerMacroNom //total 
number of microticks 

+ vMicroOverheadPerCycle; //for this 

cycle 

vRatioMicroMacro = vMicroPerCycle/ gMacroPerCycle; //real 
division, not integer 

vIntegerRatio = Int [vRatioMicroMacro] ; 
//Integer part of ratio 

vRest = VRatioMicroMacro - vIntegeri?atio; 
//Fractional part of ratio 
vJReiTiainingSuniOfFractionaiParts = vRest; 
//Initialization values for 
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vDeltaCorrect-0; //variables 

// 

DistributeMicroOverMacroRate // 
whiled) // 

vMicroPerMacroRateCorr - vIntegerRatio + vDeltaCorrect; 

//Calculate new MicroPerMacro 

vRemainingSumOfFractionalParts = 
vRemainingSumOfFractionalParts + vRest; //update 

//fractional history 

term 

if VRemainingSumOfFractionalParts >= 1 //If sum 

of fractional parts 

VDeltaCorrect = 1; //becoroes 
greater 

VRemainingSumOfFractionalParts = 
VRemainingSumOfFractionalParts -1;// than 1 

// increase macrotick 

length by 1 

else // 

VDeltaCorrect =0 // 
vMicroPerMacroCorr = vMicroPerMacroRateCorr; //if no 
offset correction present 

end; // 
[vMicrotick, vMacrotick] = 

IncrementMacrotickCounter {vMicroPerMacroCorr, vMicrotick, 
vMacrotick) 

[0360] Notes on the above Procedure: 

• The variable vIntegerRatio is not necessarily equal to pMicroPerMacroNom (may be important for implementation) . 

[0361] Open Topic: Not clear at the moment, whether vDeltaCorrect should be Initialized every cycle or once at the 
controller start. 

• Offset correction has an additional influence. Therefore there Is a difference between the variables vMicroPerMa- 
croCorr and VMicroPerMacroRateCorr. 

• Since there is no real division available in hardware, the implementation will not precisely replicate the above 
procedure. Most likely the variable vMicroPerMacroCorr not be explicitly calculated In hardware. 

• As is typically true with pseudocode, the above procedure provides Insight Into the behavior of the mechanism, 
but not its implementation. 
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Global Time Representation 

[0362] Figure 44 shows the local timing of three nodes and their relation to each other. In FlexRay node activities, 
inciuding communication, are based on the concept global time, even though each individual node maintains its own 
5 view of it. It is the clock synchronism mechanism differentiates the FlexRay cluster from other node collections with 
independent clock mechanisms. The global time Is a vector of two values, the cycle (cycle counter) and the macrotick 
counter (cycle time). 

General Concepts 

10 

[0363] 

• The node (or nodes in the case of a startup w/ith collisions) that transmit the first CAS during startup, Initializes the 
cycle counter and the cycle time to zero at the beginning of the communication cycle following the transmission 

15 of the CAS. See TBD for details. 

• The duration of a static slot gdSlot, a commun ication cycle gdCycle, and the idle time at the end of a commun ication 
cycle gdNetworkldle are all expressed as a whole number of macrotlcks. 

20 • Each node with pChannels == gChannels that is configured to send in the static segment of the communication 
cycle can send at most one frame per communication cycle with the sync bit set. 

• The sync bit may only be set in frames that are transmitted on all channels (gChannels - one or two channel 

configuration). 

25 

• Not all nodes that are configured to send in the static segment of the communication cycle need to send frames 
with the sync field set. 

• The communication controller has to count all correctly received frames each cycle where the sync bit is set. This 
30 number is accessible to the host. 

• If a controller receives more than gMaxSyncFrames the first gMaxSyncFrames are used for clock synchronization. 

• All controllers execute the synchronization algorithm approximately at the same time. The calculation of the cor- 
35 rection terms lake place every second communicalion cycle during the network idle time, 

[0364] The clock synchronization is realized with four processes called measurement, calculation, offset correction, 
and rate correction. The offset correction, measurement, and calculation processes are performed sequentially. Rate 
correction Is performed in parallel to the other three. Figure 45 shows the relative execution timing of these four proc- 
40 esses. 

[0365] Figure 46 illustrates the internal structure of the clock synchronization mechanism in more in detail. The blocks 
In the Illustration correspond to the pseudocode procedures in this chapter. The black boxes describe the tasks per- 
formed and the adjacent blue text gives the corresponding procedure name. 

45 Time Measurement 

[0366] Figure 47 shows a time difference measurement (expected vs. observed arrival times). 

• Every node measures and stores the time differences (in microtlcks) between the expected and the actual observed 
50 arrival time of all sync frames received during the static segment. 

• The expected arrival time of a frame is calculated relative to the beginning of a slot (slot boundary). The time (in 
microtlcks) between the start of a slot and the expected reception of the time reference point Is calculated as follows: 

55 • pExpectedAm'valTimeChA = gdFrameStartSequence + gdTimeReferencePoint + pDelayCompensationChA 

• pExpectedArrivalTimeChB = gdFrameStartSequence + gdTimeReferencePoint + pDelayCompensationChB 

• The global parameters gdFrameStartSequence and gdTimeReferencePoint are specified in fractional macroticks 
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but represented internally In microtlcks. This Is necessary because the only global time unit available Is the mac- 
rotlck, since microtick durations are node-specific. Fractional macrotlcks are necessary because greater precision 
is needed than can be provided by the macrotick. 

• The Observed Arrival Time is defined as the elapsed time between the start of a slot and the reception of the time 
reference point for the frame. The unit of measure is the microtick. 

• The Time Difference measurement is the difference between the Expected Arrival Time and the Observed Arrival 
Time. It is calculated and stored after each Observed Arrival Time measurement. A bit marks this value as invalid 
until the frame is received completely and passes the required validity checks. 

• The sync frame validity checks used during startup and reintegration are described in Section TBD 

• A valid sync frame during normal operation means 

• vCheckFrameCoding = tru e 

• vCheckCRC = true 

• vCheckSyncBitSet == true 

• vCheckStaticPayloadLength == true 

• vCheckFramelDMatch == true 

[0367] Open Topic: How to define the Delay Compensation value? Background: using the time value of the first 
frame can bring problems If we over compensate the wire/star delay --> explain how to define 

• For NRZ 8N1 bit coding the time reference point Is defined as the rising edge at the end of the frame start. 

• The time difference measurement Is done for all channels pChannels. 

• If there are time difference measurements from more than one channel for a given sync frame, the smallest value 
is taken. 

• If only one valid frame is received within a given static sending slot, this single observation is used for the Time 

Difference Measurement. 

• Every node has to be able to store measurement values for gSyncA/octe/Wax sync nodes. Acounterwill be increased 
when a valid sync frame is received. If a node receives more than gSyncNodeMax sync frames in one communi- 
cation cycle it raises an interrupt to the host but uses the first gSyncNodeMax observations for the calculation of 
the rate and drift correct values. 

• The Frame Identifiers of sync frames expected to be received are not stored in the configuration of a node. 

• Individual delay compensation values (pDelayCompensationChA and pDelayCompensationChB) can be config- 
ured for each channel. 

Procedure 5: Measurement 

[0368] The following procedure Is executed during normal operation following the reception of each frame In the 
static segment. 
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IvMeasureOddLlst, vMeasureEvenList] = Measurement (vCycle, 
vMeasureOddList, vMeasuzeEvenList) ; 

if sync_bit == 1; //sync bit 

in message set 

if messageChA == valid //message is 

valid 

vMeasureChA = arrival_time_chA - 
//measurement on channel A 

pExpectedArrivalTimeChA - pDelayCompensationChA; I / 
minus compensation value 

else // 

vWeasureChA = 'invalid'; //mark 
message as invalid 

end; // 

if messageChB == valid //message is 

valid 

vMsasuxeChB = arrival_time_chB - 
//measurement on channel B 

pExpBctBdArrL-valTimeChB - pDelayCompensatlonChB; // 
minus compensation value 

else // 

vMeasureChB = 'invalid'; //mark 
message as invalid 

end ; / / 

vMeasureMin = MIN (vWeasureChA, vMeasureChB) ; //save 
the minimum value of 

// both 

if MODULO ( vCycIe, 2) == 1 //separate 
in odd and even 

// cycles 
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vMea sureOddLi st = [ vMea s ureOddLis t , vMea s u reMi n] ; / / 
add minimum to list 

else //measured value 
vMeasureEvenList = [vMeasureEvenList, vMeasureMin] ; 
//add minmum to list 

end; //measured value 

end; // 

Correction Term Calculation 
Fault-tolerant Midpoint Algorithm 

[0369] The technique used for the calculation of the correction terms is a fault-tolerant midpoint algorithm (FTA/FTM) 
[10 xref TBD]. The algorithm worl<s as follows (see Figure 48 and Procedure 6): 

1 . The measured values are sorted and the k largest and the W smallest values are discarded (k is the number of 
tolerated failures per re-synchronization period). 



30 



2. The value of k Is adapted dynamically to the number of values in the sorted list. 

Table 10: 



FTA/FTM Tenn Deletion as a Function of List Size 


Number of Values 


k 


1 -2 


0 


3-7 


1 


8 - cControllerMax 


3 



3. The largest and the smallest of the remaining values are averaged for the calculation of the midpoint value. The 
resulting value is assumed to represent the node's deviation from the global time base and serves as the correction 
term. Figure 48 shows the algorithm for clock correction value calculation for k=2. 
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Procedure 6: FTMIFTA Algorithm 
[0370] 

function: vCotzectValue = Midterm {list ) ; 



30 



n = LENGTH (list) ; //number of 

elements in the list 

if n > 0 // 

list = SORT (list); //order list by 

values 

if n < 3 //k=0 
vCorrectValue = (list(l) + list(n)) / 2; 
//choose largest and smallest value 

else // 

if n < 8 //k=l 
vCorrectValue = (list(2) + list(n-l)) / 2; 
//choose second largest and second 

else //smallest value 

//k=2 

VCorrectValue = (list(3) + list(n-2)) / 2; 
//choose third largest and third 

end; //smallest value 

end; // 
else // 

vCorrectValue =0; // 
end; // 



40 * If the list contains only one value this value Is used for clock synchronization. 
Calculation of the Offset Correction Vaiue 
[0371] 

45 

1 . Tine Offset Correction Value vOttsetCorrection is a (signed) integer indicating by how many microticlcs the node 
should shift its start of the cycle. 

2. Offset caiculatlon must be finished before start of cycle, and It may only start after end of last synchronization slot. 

50 

3. The node's own offset vaiue (most likely zero, depending on the measurement principle used) must be inciuded 
if it transmits a sync Frame. 

4. The caiculatlon of the offset correction value Is done every second communication cycle, in the odd numbered 
55 cycles. 

5. If the node transmits sync frames, its own offset time is Included by adding one instance of the vaiue zero 
(depending on measurement method) to the list of measured time difference values from the last cycle 
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6. The offset correction value is determined by applying the FTA/FTiVI to the iist of measured time differences. 
Procedure 7: Offset Correction Value Calculation 
s [0372] 

vOffsetCorrection = Of fsetCalculation (vMeasLireOddList) 



30 



list = []; 

for i=l to LENGTH (vMeasureOddList) 
element of the list 

if vAfeasureOddList (i) == 'valid' 

valid 

list = [list, vMeasureOddList{i) ] ; 
write in new list 

end; // 
end; // 
if MODULO (vCycJe, 2) == 1 
number is odd 

if sync_master == 1 
sync master (means the 



//initialize list 
//for every 

//check if 

//if yes 



messages) 

list = [list, 
value to the list 



0]; 



//if cycle 
//if node is a 
//node transmits sync 

//add one zero 



end; // 
if LENGTH (list) > 0 

value 

vOffsetCorrection = Midterm(list) ; 
offset correction term 

else // 
vOffsetCorrection = 0; 
correction, warning! 

end; // 
end; // 



//at least one 
//calculate 

//no offset 



Calculation of the Rate Correction Vaiue 
[0373] 

1 . The calculation of the rate correction value is done after every second communication cycle, in the odd numbered 
cycles (see Figure 49). Figure 49 shows the timing of measurement and correction. 
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2. The rate correction value is determined by comparing the corresponding measured time differences from two 
successive cycles. Specifically, a new list of values is created wliose eiements are calculated by taking tine differ- 
ences between the most recent cycle's measured time difference and the previous cycle's measured time differ- 
ence. Only time vaiues corresponding to frames passing the validity checi<s on both channels are used. 

3. If the node transmits sync frames its own rate correction influence is considered by adding an instance of the 
value zero to the list of calculated time difference. 

4. in the next step the l=TA/FTiVI aigorithm described in Section "Fauit-toierant iVIidpoint Algorithm" is applied to 
the list of time difference vaiues built in the previous two steps. 

5. After calculating the correction term, the stored measurement vaiues are deleted so that the next caiculation 

starts with a new set of values. 

6. The ideal new rate correction value is the sum of the value caicuiated in the previous step and the current 
correction value. 

7. To prevent cluster drift that can result from an accumulation of rounding errors the rate correction term actually 
used is not the ideal rate correction, but a slight modification of this term towards the configuration value. The 
modification term is a positive integer pC/L/sferDr//ifDa/np//i£r that is part of nodes static. 

Procedure 8: Rate Correction Value Calculation 

[0374] 

vMicroOverheadPerCycle = RateCalculation { vWeasureOddList, 
vMeasureEvenList, vCycle, vMicroOverheadPerCycle) 

if MODULO ivCycle, 2) == 1 //if cycle 

number is odd 

j=l; // 
for i=l to LENGTH (vATeasureOddiist) //for all 

elements of listl and list2 

if (vMeasureEvenList (i) Valid') AND // 
(vMeasureOddList{±) == 'valid') //check if 

both values are valid 

vMeasureDif f List ij) = vMeasureOddList{i) - 
vWeasureEvenList (i) ; // if yes, build difference 

j = j +1; //and save it in 

a new list 

end; // 
end; // 

// 

if sync_master == 1 AND (two successful sync transmissions 
last two cycles) // 
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//if node is a sync 

master 

5 vMeasureDiffList = [vMeasureDiffList, 0]; //add 

one instance of zero to list 

end; // 

if LENGTH (vMeasureDiffList) > 0 //at least 

10 

one value in the list 

vChangelnRateCorrection = MidtermivMeasuzeDiffList); 
//calculate the rate correction term 
15 else // 

vChangelnRateCozrectlon = 0; //no new 

rate correction value, 

end; //warning! 

// 

vIdealRateCorrectlon = //ideal new 

value is sum of old 
2^ vMicroOverheadPerCycle + vChangelnRateCorrection; //and 

change 

if vJdealJiateCorrection >= vMicroOverheadPerCycleNom + 
pClusterDriftDamping // 
30 VMicroOverheadPerCycle - vIdealRateCorrection - 

pClusterDriftDamping: // 

elseif vIdealRateCorrection <= vMicroOverheadPerCycleNom - 
pClusterDriftDamping 11 

35 

VMicroOverheadPerCycle = vIdealRateCorrection + 
pClusterDriftDamping; // 

else // 
4P VMicroOverheadPerCycle = vIdealRateCorrection; // 

end; // 
end; // 

45 [0375] Open Topic: The last line could also use the configuration value or anything in between. 
[0376] Version 5 Solution: Use configuration parameter pClusterDriftDamping (Bbit) 

• After calculation of the correction values the memory for the measurement values is cleared and marl<ed empty. 
50 Value Limitations 

[0377] Before applying them, the calculated correction values are checked against pre-configured limits. These limits 
define two regions that are referred to as the "red" and "green" regions, where the colors reflect the acceptability of 
the calculated value (see Figure 50). 
55 [0378] If correction values are In the green region, the node is fully synchronized. No further actions are necessary. 

[0379] If one of the correction values is in the red region, the node is out of synchronization. This is a serious problem. 
Additional information on the handling of this situation is specified in chapter 8 "Error handling". 
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• The correction values are in the green region if: 

• -gRateCorrectionOut <= vMicroOverheadPerCycle <= + gRateCorrectionOut 
5 • -gOffsetCorrectionOut <= vOffsetCorrection <= + gOffsetCorrectionOut 

• if both correction vaiues are in the green area the correction is done. 

• -gRateCorrectionOut\s the iower boundary and +gRateConrectionOut\s the upper boundary of the green area for 
10 the rate correction. 

• -gOffsetCorrectionOut is the lower boundary and +gOttsetCorrectionOut is the upper boundary of the green area 

for the offset correction. 

15 [0380] Figure 50 shows the assessment of the calculated rate correction value. 

• The correction value is in the red region if 

• - gRateCorrectionOut > vRateCorrection OR +gRateCorrectionOut < vRateCorrection 

20 

• - gOffsetCorrectionOut > vOffsetCorrection OR + gOffsetCorrectionOut < vOffsetCorrection 

• The significance of having correction values in the red region depends on whether the node is in the process of 
startup, or not. During normal operation this is a critical error. During startup and reintegration it must be treated 

25 differently (see Section TBD). 

• The vaiues of gRateCorrectionOut ar\d the gOffsetCorrectionOut are identicaiiy specified for ail nodes in the ciuster 
They are defined in terms of in macroticl<s or partial of a macroticks. From these cluster-wide values the configu- 
ration data for each node is calculated (measured in microticlcs). These vaiues are included in the configuration 

30 interface. These calculations are summarized as follows: 

• pOffsetCorrectionOut = gOffsetCorrectionOut* pMicroPerMacroNom 

• pRateCorrectionOut = gRateCorrectionOut * pMicroPerMacroNom 

35 

• if the communication controller is in "normal mode" and if one correction value is in the red area the node goes to 

passive, 

[0381] Figure 51 shows the assessment of the calculated offset correction value. 

40 

Clock Correction 

[0382] Once calculated, the correction terms are used to modify the local clock in a manner that synchronizes it more 
closeiy with the global clock. This is accomplished by using the correction terms to adjust the number of microticks in 
45 each macrotick. 

• Rate correction is accompiished by modifying the value of vMicroOvertieadPerCycle (see Procedure 8), which is 
subsequently distributed over the macroticks comprising the next cycie. 

50 » Offset correction is accomplished by modifying the value of vOffsetCorrection (see Procedure 7), which is subse- 
quently distributed over the macroticks comprising the current Network idle Time. 

Offset Correction 

55 [0383] 

• Offset correction is done during the network idle time by increasing or decreasing the size of each macrotick.. 
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• It is not necessary that all controllers perfornn their offset correction identically. However, they must perform the 

offset correction In the Network Idle Time. 

• The offset correction term, vOffsetCorrection, Is a signed integer that Is visible to the application. 

• it cannot be assumed that the magnitude of the offset correction term, \ vOffsetCorrection\, is less than a macrotick. 
IHowever, it Is necessary to make assumptions on the maximum value WOffsetCorrectiori can achieve under ail 
application and fault scenarios. (The maximum offset correction value assumed has a significant influence on the 
macrotick length, slot length and other critical timing parameters.) 

• The maximum number of microtlcks that at macrotick can be increased (due to offset correction and rate correction 
combined) Is bounded by a configuration constant pMicroPerMacroMax. The offset correction term, vOffsetCor- 
rection, Is distributed across the first, and subsequent macroticks to the limit allowed by pl\/licroPerMacroMax, untii 
the total offset term is distributed. 

• The maximum numberof microtlcks that at macrotick can be decreased (due to offset correction and rate correction 
combined) is bounded by a configuration constant pMicroPerMacroMin. The offset correction term, vOffsetCorrec- 
tion, is distributed across the first, and subsequent macroticks to the limit allowed by pMicroPerMacroMin, until 
the total offset term is distributed. 

• pMicroPerMacroMax is the maximum length of a macrotick in microtlcks. 

• pMicroPerMacroMin is the minimum length of a macrotick In microtlcks. 
Procedure 9: Offset Correction 

[0384] [vMicroPerMacroCon] = 01fselCorrect\on{vOffsetCorrection, vMicroPerMacroRateCori) 
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if networkldleTime == true // 

if vOffsetCorrectian > 0 //positive 
offset 

if vOffsetCorrection > pMiczoPerMacroMax - 
vMicroPerMacroRateCorr; (I 

vMicroPerMacroCorr = pMicroPerMacroMax; I / 

vOffsetCorrection = vOffsetCorrection - // 
{.pMicroPerMacroMax - VMicroPerMacroRateCorr); // 
else // 
VMicroPerMacroCorr = vOffsetCorrection + 
VMicroPerMacroRateCorr; It 

VOffsetCorrection =0; // 
end; // 
else // 

if {VMicroPerMacroRateCorr - pMicroPerMacroMin) < 
I vOffsetCorrection I //negative offset 

VMicroPerMacroCorr = pMicroPerMacroMin; // 
vOffsetCorrection = vOffsetCorrection + // 
{VMicroPerMacroRateCorr - pMicroPerMacroMin); // 
else // 

VMicroPerMacroCorr = VMicroPerMacroRateCorr + 
vOffsetCorrection; II 

vOffsetCorrection =0; // 
end; // 
end; // 
else // 

vMicroPerMacroCorr = vMicroPerMacroCorr: II 
end; // 



Rate Correction 
[0385] 

• The rate correction term is uniformly distributed over the entire cycle (see Figure 49). 
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Procedure 10: Distribution of MIcrotlcks Over Macrotlcks 
[0386] 



[vIntergerRatio, vRest, vRema iningSumOfFractionalParts, 
vDeltaCorrect, vOffsetRemainder] = 

InitStartOfCycle (vMicroOverheadPerCycle, vOffsetCorrection) 
//This replaces InitRateStartOfCycle 

//execute at the 

beginning of every 

vMicroPezCycle = gMacroPerCycle * pMicroPerMacroNom 
//second cycle 

+ vMicroOverheadPerCycle; // 
vRatioMiczoMacro = vMicroPerCycle / gMacroPerCycle // 
vlntegerRatlo = lnt[vRatioMicroMacro] ; // 
vRest = VRatioMiczoMacro - vintegerRatio; //value 

between 0 and 1 

vRemainingSumOfFractionalParts = vRest; // 
VDeltaCorrect = 0; // 
vOffsetRemainder = vOffsetCorrection; 
//Additional variable 



{vMicroPerMacroCorr, vintegerRatio, vDeltaCorrect, 
VRemainingSumOfFractionalParts, vRest, vOffsetRemainder] = 
DistributeMicroOverMacro ( vj/itegeri?a tio, vDeltaCorrect, 
VRemainingSumOfFractionalParts, vRest, vOffsetRemainder) 
//This replaces DistributeMicroOver 

//MacroRate 

while(l) // 

vMicroPerWacroEateCorr = vintegerRatio + vDeltaCorrect! 
//Rate correction part 
VRemainingSumOfFractionalParts = 

VRemainingSumOfFractionalParts + vRest; // 
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if vRemainingSumOfFractionalParts >= 1 // 

vDeltaCorrect =1; // 

5 

VRemainingSumOfFractionalParts = 
VRemainingSumOfFractionalParts -1; // 

else // 
10 VDeltaCorrect = 0; // 

end; // 
vMicroPerMacroCorr = Of fsetCorrection ( vOJfjfsetJRemainder, 
vMi croPerMa croRa teCorr) / / 

15 

[vMicrotick, vMacrotick] = 
IncrementMacrotickCounter {vMicroPerMacroCorr i vMicrotick, 
Macrotick) 

20 end; // 

[vMacrotick, vCycle] = ChangeOfCycleCount ( vMacroticJc, 
vCycle) // 

25 

[0387] Procedure notes: 

• This is oniy an exampie. 

30 • As previously mentioned, it seems to be uniil<ely that the variabie vMicroPerMacroRateCorr can be caicuiated 
explicitly in hardware, it is more lil<ely that the incrementiVlacroticlcCounter procedure wlii be an Intrinsic part of at 
ieast the rate part of the microticl< distribution state machine. 

External Clock Synchronization (only for V5) 

35 

[0388] During normal operation, two independent clusters can drift significantly during normal operation (e.g., by the 
damping factor of each cluster). If synchronous operation Is desired across the two clusters, external synchronization 
is necessary; even though the nodes within each cluster are synchronized. This can be accompiished with the syn- 
chronous application of host-deduced rate and offset correction temns to both ciusters. 

40 

• Both the external rate and external offset correction have to be performed in the same cycle. 

• The external correction terms (offset and rate correction terms) have to be available to the communication controller 
when the network idle time starts. 

45 

• The external correction terms will be checl<ed against limits and applied following the corresponding tasks are 
perfomned for the internal correction terms. This takes place during the Network idle Time. 

• Following the Network idle Time, an aggregate rate correction tenn 

50 

• The aggregate offset correction term, consisting of correction components from the internal and external offset 
correction terms, will be applied in the remainder of the Network Idle Time, before the next cycle starts. 

[0389] Open Topic: in soft reset, the initial external rate correction can be accompiished two ways: 

55 

• Option 1 ; by setting the external rate correction term 

• Option 2; by setting the variabie vMicroOverheadPerCycle 
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Dependencies 
Host Interface 

5 [0390] The following table summarizes the host interface registers supporting external clock correction: 



Table 11: 



Host Interface Registers for External Clock Correction 


Register 


Size 


External offset correction register 


8 Bit 


Internal offset correction register 


8 Bit 


gOffsetCorrectionExternalOut 


8 Bit 


External rate correction register 


8 Bit 



[0391] Comment: gOffsetCorrectionOut + gOffsetCorrectionExternalOutrriusX be configured such that their sum is 
less than or equal to the reserved bandwidth for offset correction within the network idle time. 

20 

Checks 

[0392] The following rate and offset correction limit checks are perfonned: 
25 • check internal offset con-ection value vOffsetCorrection against gOffsetCorrectionOut, 

• check external offset correction value separately against gOffsetCorectionExternalOut 

• check sum of internal and external rate correction against gRateCoirectionOut. 

30 

Error Handling 

[0393] The following error conditions can arise from the rate and offset limit checks: 

• sum of internal and external rate correction is in the red region 

• internal rate correction in the red region 

• internal offset correction in the red region 

40 

Chapter 8 

Startup and Reintegration 

^5 [0394] Corresponding to the two supported protocol operation modes and their media access schemes, two different 
mechanisms for communication startup are specified. Networks operating In FlexRay mode with a static segment 
configured follow a fault-tolerant, distributed startup strategy (refer to transitions indicated by prefix 'S'; see Figure 54), 
while networks configured with a pure dynamic media access scheme perform a master driven startup (state transitions 

with prefix 'D'; see Figure 55). The protocol operations related to synchronization of the running communication sched- 
50 uie, integration of further nodes to a running cluster, media access ruies and error handling are different for the two 
configuration alternatives. Therefore, configuration-specific state diagrams for each of these configurations with state 
descriptions and state transitions are given in the foiiowing sections. The generai startup mechanism is described in 
Section "Protocol Startup". The protocol state machine does not inciude the 'wake-up' path. The networl< wake-up must 
precede the communication startup, in order to ensure that all mechanisms defined for the startup work properly. After 
55 initial wake-up the whole network behaves like a broadcast medium. 
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Startup States - Global Structure 

[0395] Figure 52 shows a global structure of a protocol state diagram. From the SoftRe set stale, one of two distinct 
startup state machines is entered depending on how the configuration settings are chosen. For pure static or mixed 
5 static/dynamic configurations the fault-toierant, distributed startup is triggered by the transition G1 . For pure dynamic 
configurations it depends on whether a node is a master node or not, when deciding which transition (G2 or G3) the 
startup state machine has to take. 

[0396] State transitions marked with the suffix 'c' are aligned to cycle boundaries, state transitions tagged with an '!' 
are executed immediately, i.e. as soon as the specific condition becomes true. 



Transition 
Direction 





61 


SoftRese 
t 


ListenSt 
atic 


soft reset released 
(in the respective control 
register) 
AND static segment configured 

igNumberofStaticSlots greater than 


G2 


Listen 
Dynamic 


soft reset released 
(in the respective control 
register) 
AND pure dynamic media access 
configured 

igNumberofStaticSlots equal to 
zero) 

AND slave role configured 
ipMaster not set) 


G3 


Normal 
Ma s ter 


soft reset released 
(in the respective control 
register) 
AND pure dynamic media access 
configured 

igNumberofStaticSlots equal to 

zero) 

AND master role configured 
(pMasCer set) 



Table 12: Global Startup State Transitions and Respective 



Conditions for Execution 

40 

' A minimum of at least two static slots is required for a pure static or mixed configuration in FlexRay 



45 SoftReset State 

[0397] The SoftReset state is part of the overaii protocol state diagram and is not just a component of startup and 
reintegration. The host configures the communication controller while it is in SoftReset state. If the communication 
controiier is in any other state, the host must force the communication controllerto re-enter the SoftReset state In order 
50 to change it's configuration. 

Startup States - FlexRay Mode with Static Segment Configured 

[0398] In general, a node may enter communication (i.e., the Wor/ra/Sfaf/cstate) via the coldstart path [ColdStarttCW 
55 and ColdStartPCW state sequence) initiating the schedule synchronization, or via the Integration path (InitRate, fn- 
itSchedule, and /nfagfraf/'onPCM/state sequence) integrating into an existing communication schedule. Only sync nodes 
are allowed to enter via the coldstart path, and they have to check in advance whether there is already network channei 
activity, or not (see Section 0). A node Is called a SYNC node if the host has set pSyncNode in the host interface. For 
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a non-SYNC node, pSyncNode is set to False. The configuration parameter can only beset or cleared In tine SoftReset 
state. The transmission of more than SYNC frame within one cycle has to be prevented bythe communication controller. 
[0399] For networks with a static segment configured, the initial synchronization of the periodic TDM A schedule must 
be coordinated among all connected communication nodes. Since all sync nodes are authorized to initiate the schedule 
synchronization, simultaneously started and conflicting attempts by different sync nodes must be resolved. Each node 
initially transmits a Collision Avoidance Symbol (CAS, see Section "Frame Validation") specifically for this purpose, 
before initiating the periodic schedule. This symbol represents a kind of arbiter, which is used to resolve initial collisions 
of nodes trying to set up the communication schedule at the same time. 

[0400] Non-sync nodes as well as sync nodes start passive integration as soon as they receive sync frames from 
which to derive the TDiVIA schedule information. During integration the node has to adapt its own clock to the global 
clock (rate and offset) and has to make its cycle time consistent with the global schedule observable at the network. 

Afterwards, these settings are checked for consistency with all available network nodes. Only if these checks are 
passed, can the node leave the integration phase and actively participate In communication. 
[0401] Several modes are supported, which restrict the node's ability to communicate or to initiate the startup actively 
(see Sections "Listen-Only Mode" and "ColdStart-inhibit Mode"). These modes are configurable by the host and are 
explained within in their respective sections. 

Frame Validation 

[0402] The semantic information that can be derived from the received data stream varies with the protocol state of 
the node. Certain frame validation checks have to be passed by a received frame or symbol, in orderto be an appropriate 
input for the related logic block. 
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10 

T - Test outcome is 
True 

F - Test outcome is 
False 

X - Test outcome is 
irrelevant 

Table 13: Frame Check Sets 

' AH checks based on a comparison of the infoimatioa gained bam the different channels are considered 

20 passed (T) if only one value is available. 

^ The term 'corrupted frame pattern' does also include corrupted symbols 

* The syntax of the CAS (Collision Avoidance Symbol) is the same as the SOC Nomial symbol used in 

pure dynamic configurations (refer also to the coding diapter). 
25 ' The term SOC is used to aggregate the two dynamic SOC symbols, SOC Nomial and SOC Alarm 

without distinguishing which one is observed. In essence, a SOC is observed if either an SOC Normal symbol or 
an SOC Alarm symbol is observed. 



30 [0403] Table 13 above, enumerates the relevant sets of checks that have to be passed In order to conclude that 
certain startup-relevant events have occurred. 

Listen-timeout and Listen-timeout with Noise 

35 [0404] A sync node maintains two different timers, vdSlartup and vdStartupNoise, which serve as listen-timeouts in 
order to leave the initial sensing phase {ListenStatic state) with the intention to start up the communication. 
[0405] The node local listen-timeout vdStartup has the same length (gdStartup) for each node in the system, which 
is configured to send an initial GAS during startup (sync node). vdStartup limits the listen time that used by a node to 
determine if there is already communication between other nodes or at least one sync node actively requesting the 

40 integration of others. If communication channel activity is detected on one of the configured pC/7an/ie/s channels while 
the node is in the ListenStatic sXaXe, the listen-timeout vdStartup is restarted. (Any signal edge detectable atthe receiver 
(i.e., a signal edge, which has passed the glitch filter) is referenced to as "channel activity". In case a 3-level physical 
layer representation is used, the same definition applies for an edge visible at the signal port, which Indicates a level 
at the channel different from idle. Again, this is checked after the signal has traversed the glitch filter.) The reception 

45 of a valid SYNCFramestartupEven causes the node to enter the integration path. Upon leaving the ListenStatic slate, 
the listen-timeout is stopped. 

[0406] As soon as the listen-timeout vdStartup expires (vdStartup=gdStartup) a node that is configured to initiate 
the startup actively enters the coldstart path and attempts the active network startup. Figure 53 shows listen-timeouts 
vdStartup and vdStartupNoise. 

50 [0407] At the same time as the listen-timeout vdStartup is started the first time, the second timeout vdStartupNoise 
is started. This additional timeout is used to Improve reliability of the startup procedure in the presence of noise. As 
soon as the timeout vdStartupNoise expires {ydStartupNoise=pdStartupNoise'gdStartup) without a valid 
SYMCFramegtartupEven being received on any of the configured communication channels, the sync node enters the 
coldstart path and assumes responsibility for initiating communication startup. Since the timeout vdStartupNoise wot^'t 

55 be reset if channel activity is sensed (see Figure 53), this timeout defines the fallback solution that guarantees that a 
node tries to startup the communication cluster even in the presence of noise. The expiration of vdStartupNoise and 
the resulting entry into the coldstart path is captured in the variable vNoise (vNoise is set to 'true'). 
[0408] Version 5 Solution: A node in CoWSta/t/CI/V state (see Section Startup State Diagram) shows a certain ro- 
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business against noise due to the definition of a vaiid Ineader pattern (see Tabie 13), winich lias to be received in order 
to return to tine ListenStatic state, if tlnis specification Is changed in the future in a way that the node in ColdStartlCW 
state is aiso susceptibie to noise (= corrupted frames), the variable vNoise has to be evaluated during the coidstart 
phase. With that value, the node Is able to distinguish whether the ColdStartlCW slate has been entered due to expl- 
5 ration of vdStartupNoise or nol. If vA/o;seistrue, the nodemustsustain the coidstart phase (i.e., remain in ColdStartlCW 
state) even in the presence of noise. At least for this specific case a definition of valid header pattern that Is distin- 
guishable from noise must existi 

[0409] The time-out Interval gdStartup Is constrained by the following Inequality. gdStartup Is derived Internally from 
the given configuration parameters gdCycle and gdMaxDrift. In addition, the upper boundary for the listen timeout 
10 VdStartupNoise is a multiple of gdStartup and Is configurable using the parameter pdStartupNolse. 
gdStartup > gdCycle + gdMaxDrift 

[0410] Due to the initial clock drift between nodes that are already actively communicating (transmitting sync frames) 
and the node that Is attempting to integrate, the listen-timeout must cover the maximum accumulated drift over the 
free-running, unsynchronized period, 
15 [0411] The maximum allowable drift between any two clocks in the network Is an important system parameter and 
known at design time. This 'worst case' period has to be covered by configuring gdMaxDrift (unit: macroticks) accord- 
ingly. Furthermore, the nominal time between two trigger events caused by regular communication pattern is always 
smaller than one communication cycle gdCycle. 

20 Listen-Only Mode 

[0412] The 'listen-only' mode Is configured by setting vListenOnlywhWe in the So/ifflesef state. vL/sfenOn/y cannot 

be set after leaving the SoftReset stale, but can be cleared at any time. In listen-only mode, the node is able to receive 
all frames after integration to the running communication; I.e. the node is fully synchronized and performs the clock 
25 synchronization In orderto keep this status, in comparison to the normal operation mode (Worma/Sfaffc state) the node 
does not actively participate in communication, l,e. neither symbols nor frames are transmitted. 
[0413] This mode supports communication diagnosis ('monitoring') as well as dedicated wake-up strategies, which 
require host Interaction (vZ./sfer70n/ysubsequently cleared) In orderto actively participate in communication after wake- 
up. 

30 [0414] In listen-only mode, sync nodes behave like non-sync nodes during startup. Specifically, this applies to the 
prerequisites for transitioning from IntegrationPCW lo StaticPasslve. Passing the plausibility check requires that at 
least two different sync nodes are already synchronized and able to communicate. Please refer to the description of 
the plausibility check In Section "InitSchedule State". 

35 ColdStart-lnhlbit Mode 

[0415] The node can be prevented from initializing the TDMA communication schedule by setting vColdStartlnhibit 
in the Soffflesef state, vColdStartlnhibit camol be set after leaving the Softffesef state, but can be cleared at any time. 
vColdStartlnhibit can be mapped to the grCo/dSfa/t/Max configuration parameter, which utilizes the zero value as to 
40 keep the node from starting the network on its own Initiative (refer to the chapter "host interface"). It has to be checked 
whether the parameter ^Co/c/Sfa/tA/fax can be accessed during run time. I.e., after leaving So/ifHesef state, as this Is 
required for the "coidstart Inhibit" function. 

[0416] If the host has set vColdStartlnhibit, the node Is not allowed to initialize the cluster communication after having 
checked on existing communication. The node is allowed to Integrate to a running cluster or to acknowledge another 

45 node, which initially tries to start the cluster communication, 

[0417] Once the node is synchronized, vColdStartlnhibit does not restrict the node's ability to receive frames or to 
transmit frames. 

Startup State Diagram 

50 

[0418] Figure 54 shows a startup state diagram - FlexRay Mode with Static Segment Configured. 
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State 
Transit 


Transition 
Direction 


Condition for Transition 


ion 


from 


to 






Sli 


Listens 
tatic 


ColdSta 
rt 
ICN 


node is configured as a sync 
node {pSyncNode==tzue; 
gColdStartMax>0) 

AND vColdStartCount < 
gColdStartMax 

AND vListenOnly is not set 

AMD vColdStartlnhibit is not set 

AMD listen-timeout vdStarti^ 
{ expired 

{vdStartup^^^gdStartup) 

OR listen-timeout with 
noise vdStartupNoise 
) expired (vJVoise==l) 


S2i 


InitRat 

e 


reception of a valid 
SYNCFramestattupEvan on one of 
pChannels channels* 



° Since the state transition is performed immediately (indicated by suffix i), a 'pick first' strategy for 

S VNCFramesuniffyn interpretation is specified. The node does not check, whether there is also a corresponding 
SYNCFramesamipEwn at the second channel or not. As soon as one valid SYNCFrainesa„,pE,„ has been received, 
an ongoing reception at the other channel can be aborted. In no case should the subsequent delayed reception of 
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Transition , Condition for Transition 

Direction 

from to 









AND vRefSync == 0 
( (no integration 

history available) ' 

OR fFramelD is different 
) from vRefSync 


S3i 


Colds ta 
rt 
ICW 


Listens 
tatic 


( end of current cycle 
(derived from local 
cycle time) 

AND vColdStartCount is 

equal to gColdStartMax 

) OR reception of a valid CAS 

symbol on one of pChannels 
channels 

OR reception of a valid header 
pattern on one of pChannels 

channels 


S4c 


ColdSta 
rt 
PCW 


not S3i 

AMD end of current cycle 
{ (derived from local 
cycle time) 

AND vdlnitialCheckWindow 
expired 

[vdlnitialCheck^indow 

) 

gdIn±txalCheck9iindow) 



a corresponding SYNCFiamCsuiq^vQi at the second channel be interpreted as the trigger event for die succeeding 
state transition S8t! 

' Due to this definition it is possible that a node stops current startup process (re-enter ListenStaiic from 

ColdStartlCW), even though there hasn't been any possibility for other nodes to answer until dien. 
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State 


Transition 


Condition for Transition 


Transit 


Direction 




ion 








from to 





S5c 


ColdSta 
rt 
PCW 


Listens 
tatic 


( end of current cycle 
{derived from local 
cycle time) 

MUD vColdStartCcunt is 

equal to gColdStartMax 

AND not S6c 

) 

OR ( end of current cycle 
(derived from local 
cycle time) 

AND vInvalidSyncCount t 
) vValidSyncCount 

OR ( end of current cycle 
(derived from local 

cycle time) 

AND 1 vOffsetCorrectionI > 
pOffsetCorrectionOut 

) 

OR { end of current cycle 
(derived from local 
cycle time) 

AND 1 vMiczoOverheadPerCycl 
el > 

) pRateCorrecticnOut 


S6c 


ColdSta 
rt 
PCW 


normal 
Sta tic 


end of current cycle 
(derived from local cycle 
time) 

AND VInvalidSyncCount < 
VValidSyncCount 

AHD vSyncPairs is true 

AND [vOffsetCorrection] ^ 
pOffsetCorrectionOut 

AiTO \ vMicroOverheadPerCycle\ < 
pRateCorrectionOu t 



' Ic is assumed that the vOffsetConection is set to zero for cycles with even cycle counter value [(vCycle 
MOD 2)=0] by the clock synchronization unit 

' This check reflects the check on 'matching the valid range' for die rate correction term. The current 
defioiticn in the chapter 'clock synchronization' refers to vRatcConection, but is not consistent in the adhering 
description 
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State 
Transit 


Transition 
Direction 


Condition for Transition 

u 


ion 


from 


to 






S7i 


InitRat 
e 


Listens 
tatic 


timer vdlnitRateMLate 
expired 

(valid SYNCFramestartupOdd with 
fFramelD = vRefSync too 
late) 

with fFramelD = 
vRefSync received 

AND timer 

vdini tialRateMEarly 
has not been started 
) (occurrence of frame 
too early) 


S8i 


InitSch 
eduJe 


not S7i 

AND valid SYNCFramestartupOdd with 
fFramelD = vRefSync 
received^" 


S9c 


InitSch 
edule 


Integra 
tion 
PCW 


end of current cycle 
(derived from local cycle 
time) 



'Pick first' strategy is applied; refer also to transition S2i 



5/19/2010, EAST Version: 2.4.1.1 



EP 1 355 456 A1 



State 
Transit 


Transition / 
Direction 


Condition for Transition 


ion 


from 


to 


- 




SlOc 


Integra 
tion 
PCW 


Listens 
tatlc 


( end of current cycle 
(derived from local 
cycle time) 

vlnvalidSyncCount > 
) vValidSyncCount 

OR ( end of current cycle 
(derived from local 
cycle time) 

AND vOffsetOut == true 

(an offset correction 
value greater than 
pOffsetCorrectionOut 
has already been 
accepted once) 

AND \vOffsetCorrection\ > 
pOffsetCorrectionOut 

> 

(derived from local 
cycle time) 

AND 1 vOffsetCorrection 1 > 
2* 

) pOffsetCorrectionOut 

OR { end of current cycle 
(derived from local 
cycle time) 

AND \vMicroOverbeadPerCycl 
el > 

) pRateCorrectionOut 


Sllc 


Norma 1 
Static 


not SlOc 

AMD end of current cycle 

(derived from local cycle 
time) 

AND VlnvalidSyncCount < 
VValidSyncCount and 

(vCycle MOD 2) == 1) 

AND vSyncPairs is true 
AND vLlstenOnly is false 

AND \ VOffsetCorrection \ < 
pOffsetCorrectionOut 

•WI* 1 vMicroOver/ieadPerCycJel < 
pRa t eCorrec tionOut 
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State 


Transition 


Condition for Transition 


Transit 


Direction 




ion 


from 


to 





S12c 



S13i 



S14i 



Passive 
Static 



All 
States 



30 



Passive 
Static 



Norma 1 
Static 



Soft 
Heset 



AMD 

AMD 

AMD 
AMD 
AMD 

AMD 



not SlOc 

end of current cycle 
(derived from local cycle 
time) 

vInvalidSyncCount < 
vValidSyncCount and 
{vCycle MOD 2) == 1) 

vSyncPairs is true 

vListenOnly is true 

\vOffsetCorrection\ < 
pOffset Correct! on Ou t 

\vMicroOverheadPerCycle\ < 
pRa teCorrectionOut 



AMD 



end of current cycle 
(derived from local cycle 
time ) 

vListenOnly is false 



soft reset initiated 

(in the respective control 

register) 



Table 14: 

Execution 



State Transitions and Corresponding Conditions for 



35 ListenStatic State 

[0419] All nodes enter the ListenStatic slale after being released from the SoftResef state. In this state the commu- 
nication controller is ready to attempt network startup or enter a running network. When entering the ListenStatic state 
from SoftReset or re-entering from integration path {InitRate, InitSchedule, and IntegrationPCW state sequence) , sync 

40 nodes start their listen-timeout vdStartup and their iisten-timeout with noise vdStartupNoise. Networl< activity on any 
of pChannels channeis, which is different from a vaiid SYNCFrames^rtupEven causes a restart of the iisten-timeout 
VdStartup. if ListenStatic is entered from ColdStartlCW or ColdStartPCW because the maximum number of coidstart 
attempts has been reached (vColdStartCount^ gColdStartMa)i), the listen-timeouts are not re-started, if the node just 
faiied duetothe iCW or PCW checi<s (see Sections "CoidStartlCW State"and "CoidStartPCW State"), the iisten timeout 

45 vdStartup is restarted and vdStartupNoise is resumed from the iatest vaiue. Non-sync nodes do not have any iisten- 
timeouts. 

[0420] When either timeout (vdStartup or vdStartupNoise) expires, the other is aiso halted in the transition to the 

CoWSfarf/C 1/1/ state. 

[0421] In order to maintain a fallback strategy to apply after an integration attempt falls (see Section "Protocol Star- 
so tup"), nodes in ListenStatic start the timer vdCycleWithHIstory if vRefSync is nonzero. This timer covers the same 
period gdStartup as the vdSfa/tuptimeout, but its restart condition Is defined differently, if a vaiid SYNCFramestartupEven 
with fF/ame/D equal to vRefSync\s received, no transition into InitRate takes place. Only if vdCycleWithHistory expires, 
is vHefSync cleared. This setting {vRefSync=0) prevents the restart of vdCycleWlthHistory. Channel activity different 
from valid SYNCFramestartupEven restart vdCycleWittiHistory. Before entering InitRate on reception of a valid 

55 SYNCFramestartupEven {vRefSync^ or fFramelD not equal to vRefSync) fFramelD is stored to vRefSync and vdCy- 
cleWitiiHistory \s cleared and halted. 

[0422] When re-entering L/sfenSfaf/c state from any state, the rate correction value has to be reinitialized with pMi- 
croOvertteadperCycleNom. 
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ColdStartlCW State (The acronym "ICW" stands for Initial Check Window) 

[0423] Only sync nodes are allowed to enter the ColdStartlCW stale. These nodes leave ListenStatic when a listen- 
timeout or listen-timeout with noise occurs before receiving a valid SYNCFramcstartupEven- '^^ Co/dSfarf/CIA' state, a 
5 sync node transmits the initial CAS and then cyclically transmits its configured sync to enable the startup of the entire 
networl<. If more than one sync node's listen-timeout or listen-timeout with noise expires before a valid 
SYNCFramestartupEven is received, they all enter ColdStartlCW. In ColdStartlCW norma] data frames (without sync bit 
set) are not transmitted. 

[0424] With the transition into ColdStartlCW Xhe variable vColdStartCount is incremented by one. At the end of each 
10 cycle, vColdStartCount\s compared to the allowed maximum gColdStartMax. After having spent gColdStartMax cyc\es 
attempting to achieve communication with another node (transition to NormalStatic stole), the node re-enters Listen- 
Static. This measure ensures that a node unable to receive a valid SYNCFrames[a^,jppcw fi'om at least one of pChian- 
ne/s channels, i.e. a node with 'incoming link failure', stops transmission after a predefined interval of time and thereby 
enables other nodes to assume the responsibility for starting communication for the cluster. 
15 [0425] With each new cycle-start In the CoWSfarf/CM/ state, vColdStartCount is incremented by one. 

[0426] The node remains in ColdStartlCW ^or a period determined by the Initial check window (gdlnitialCiieckwin- 
dow). The timer vdlnitialCheckWindow is started, when ColdStartlCW \s entered, and thus covers the initial slot used 
for CAS transmission as well as three complete communication cycles (refer to definition of gdlrjitlalCheckWmdow in 
Section TBD). Consequently, gdlr)ltialChecl<Wlndow determ'mes the time a node stays In Co/e/Sfarf/CM/before entering 
20 ColdStartPCW. In order to take all reception events into account, this window does not have any gap, i.e. it also includes 
the network idle time (compare with the definition for gdPlausibilityCheckWindoviA) Due to the fact that the node is not 
capable to receive during its own transmissions, the network observation is suspended during them. 
[0427] The reception of a valid CAS symbol or valid header pattern causes the node to immediately re-enter Listen- 
Static. With the transition into another state the timer vdlnitlalCiieckWindow is stopped. 

25 

ColdStartPCW State (The acronym "PCW" stands for Plausibility Check Window) 

[0428] In Co/ofSfartPCIA'the node continues transmitting its sync frame periodically. In addition, the node performs 
a plausibility check in order to assess the network image gained during a bounded receive period determined by the 
30 plausibility check window gdPlausibllityCheckWIndow. 

[0429] Version 5 Solution: Since running receptions are stopped with the beginning of the network idle time and 
no further reception events during network idle time are considered for the actual cycle, the gdPlausibilityCheckWmdow 
period starts with each new cycle and ends with transition into network idle time. 

[0430] After each observation phase (gdPlausibiiityCheckWindov/} the node evaluates the results. The node re-en- 
35 ters ListenStatic if an inconsistency is observed regarding the number of valid SYNC frames received, and the node's 
observation matches the minority. On the other hand, the node is allowed to enter NormalStatic If the plausibility check 
is passed (vlnalidSyncCount<vVaiidSyncCount; see also the conditions for counter increment below). Two event 
counters (vValidSyncCount and vInvaiidSyncCount) are administrated in order to support decision-making. In accord- 
ance with the receive window definition, a clear distinction between several possible cases can be made for each slot. 
40 These slot scenarios are judged and counters are incremented according to the following rules (where x stands for 
channel A or B and y stands for the respective other channel): 



if valid SYNCFraraestartupPcwX and 
( 

nothing at the other channel y or 
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corrupted frame pattern y or 

valid SYNCFramestartuppcwy 

) 

vVa 1 i dSyncCoun t++ ; 
end; 

elseif (invalid SYNCFramestattuppcwX and 
( 

nothing at the other channel y or 
corrupted frame patterny or 
valid SYNCFramestartuppcwy or 
invalid SYNCFramestartuppcwy or 
valid DataFramestartupPcwy 
) ) or 
(valid SYNCFramestartupPcwx and 
valid DataFramestartupPcwy) 

vlnvalidSyacCount++ ; 
end; 



[0431] The plausibility checks are Initialized as follows: 
25 vValidSyncCount=^■, 
vlnvalidSyncCount =0 ; 

[0432] The plausibility check is passed, if vValidSyncCount is greater than vlnvalidSyncCount. The transition to Nor- 
30 malStatic Is only permitted, If the check Is passed with vVeJidSyncCount>^ , since the node considers Itself correct and 
has therefore initialized the counter accordingly. If the value of vValldSyncCount \s still one, there has been no valid 
determination so far and the node remains in ColdStartPCW slate for another cycle. 

[0433] With the transition to ColdStartPCW and with each new cycle start in ColdStartPCW, the variable vColdStart- 
Count 'is Incremented by one. At the end of each cycle, vColdStartCount is compared to the allowed maximum gCold- 

35 StartMax. 

[0434] In ColdStartPCW the node continues executing the global clock synchronization for offset and rate according 
to the regular rules (already started during ColdStartlCW state). According to the definition of the regular rate meas- 
urement phase, ail sync frames are registered and pair-wise (sync frames with same frame identifier) evaluated for 
clock synchronization. 

40 [0435] The offset measurement phase Is applied In accordance to the regular scheme, too. This means that for each 
cycle with an odd cycle counter value the related sync frames are used to determine next offset correction term. 
[0436] The node In ColdStartPCW state requires at least one additional matching pair of sync frames suitable for 
rate measurement (same frame identifier, consecutive occurrence In 'even/odd' cycle order), in order to fulfill one of 
the necessary prerequisites for entering NormalStatic. As long as the node does receive a response, it performs the 

45 clock correction based on one "pair of matching sync" frames, namely its own transmissions (the value 0 is assumed). 
As soon as another node is recognized that answers with two valid SYNCFramestartupPcw transmissions in even/odd 
cycle order, the node in ColdStartPCW \s acknowledged by at least one other sync node and vSyncPairs is set to true. 
With the beginning of each rate measurement phase in ColdStartPCW slate, the variable vSyncPairs is reset to false. 
[0437] In addition to the prerequisite that necessary sets of measurement samples are available (vSyncPa;rs is true), 

50 the quality of the resulting correction terms for clock synchronization is assessed. The nodeisonly permitted to execute 
transition Into NormalStatic state, If the correction terms for both, rate and offset are below the configured limit settings 
(\vOffsetCorrectiorH < pOffsetCorrectionOut and \vMicroOverheadPerCycle\ < pRateCorrectionOut). If one of the cor- 
rection temns violates the limit settings, the node has to re-enter L/sfenSfaf/c state. 

55 /n/Wafe State 

[0438] All nodes in L/sfenSfaf/c state enter InitRate after receiving a valid SYNCFramestartupEven. if the prerequisites 
for a state transition into ColdStartlCW state have not already been met. vRefSync contains the identifier of the sync 
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frame that was used to enter the integration path. The sync node corresponding to this reference frame is caiied the 
reference node. InitRate is used to derive an initiai rate correction value in order to adjust the iocai macroticl< timing to 
the timing given by the reference node. To accomplish this, the time between the initiai occurrence of the reference 
frame and its next occurrence is measured and the difference from the nominai cycie iength is appiied as the rate 
5 correction term. The initiai reception of the reference frame (which causes the state transition into InitRate) starts a 
timer. This timer covers gdCycle running in local macroticks and according to this timer a receive window is opened. 
pdlnitRateMEarly microtlcks before the timer expires, the early receive window Is opened and with the expiration of 
the timer, pdlnitRateMLate Is applied to form the late receive window. 

[0439] For two nodes running with exactly the same clock rate (with same macrotick period) the next reference frame 
10 would occur after gdCycle. 

[0440] If next valid reference frame (vaild SYNCFramegjarf^pQ^iji with fFramelD = vRefSync) matches with one of 
these two windows, the corresponding rate correction value can be directly derived. 

[0441] As soon as the rate correction term Is available, the node runs with the corrected rate (direct application of 
the correction temi). 

15 

InitSchedule State 

[0442] The reference frame used for initial rate correction (which causes the state transition Into InitSchedule state) 
Is also used to determine the nominal schedule position, using the received Identifier fFramelD. The node sets Its iocai 
20 cycle time accordingly. I.e. it synchronizes the micro- and macrotick counters to the SOF in the received sync frame. 
In addition, the cycle counter value fCycleCount of the received sync frame is extracted and used to Initialize the iocai 
cycle. 

[0443] At this point the local schedule has been established according to the information derived from the reference 

node. 

25 [0444] The node follows the iocai schedule until the end of the current cycie without transmitting actively. Any further 
reception is ignored and neither rate nor offset measurements are performed. At the end of the cycle, the transition is 
made from InitSchedule to IntegrationPCW. 

Integration PCW State 

30 

[0445] As long as the node stays In IntegrationPCW slate, the node Is not allowed to schedule transmissions. 
[0446] In IntegrationPCW the node tries to confirm the settings copied from the reference node with the overall 
network communication scheme. For this purpose the node performs a cycle-based plausibility check similar to the 

check defined for the CoWSfarfPCH/ state (see Section "ColdStartPCW State"). 
35 [0447] The observation phase gdPlausibilityCheckWindow and the conditions for Incrementing the counters (vVa- 
lidSyncCount and vlnvalidSyncCounf) are the same. Since the node still behaves passively, the initialization of these 
counters differs from that for a node in ColdStartPCW (which transmits an own sync frame and thus, participates 
actively to the plausibility check). The values used are: 

40 vValidSyncCount =0 ; 

vInvalidSyncCount =0 ; 

[0448] The plausibility check Is passed If vValidSyncCount Is greater than vInvalidSyncCount. Transition into Nor- 
malStaticcan only take place if the check has been passed, but there are additional checks to pass (see clock correction 

45 term assessment and next paragraphs, respectively) before a node is allowed to join communication with the transition 
into the NormalStatic state. The plausibility check always runs concurrently with these additional checks until the plau- 
sibility check itself fails or a state transition due to another condition is executed. 

[0449] When the node enters IntegrationPCW, a regular measurement phase for the next rate correction term is 
started. The definition of state transitions forthe protocol state machine automatically keeps the required 'grid' (starting 

50 with a cycle with an even cycle counter value). According to the definition of the regular rate measurement phase, all 
sync frames are registered and pair-wise (sync frames with same frame Identifier) evaluated for clock synchronization. 
The offset measurement phase is applied In accordance to the regular scheme, too. This means that for each cycle 
with an odd cycle counter value the related sync frames are used to determine next offset correction term. 
[0450] An Integrating sync node requires at least one matching pair of sync frames suitable for rate measurement 

55 (same frame Identifier, consecutive occurrence In 'even/odd' order) in orderto fulfill one of the necessary prerequisites 
to enter NormaiStatic state. Using this pair of sync frames, the node can acknowledge an existing node in ColdStart- 
PCW or simply integrate to a synchronized cluster. For sync nodes that do not operate In listen-only mode (vListenOnty 
Is false), vSyncPairs Is set to true as soon as the first matching pair of sync frames is received. If a sync node Is 
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configured as a listen-only node (vListenOnly '\s true), it has to fuifiil the same condition as non-sync nodes. These 
nodes need to receive at least two matching pairs of sync frames suitable for rate measurement (same frame identifier, 
consecutive occurrence). 

[0451] Only if there is already a communication established including at least two sync nodes (nodes in NormalStatic 
5 state) can the non-sync nodes (or sync nodes in listen-only mode) join in. 

[0452] For these nodes vSyncPairs is set to true as soon as two matching sync frames are part of current rate 
measurement period. 

[0453] With the beginning of each rate measurement phase in IntegrationPCWstale, the variable vSyncPairs is reset 
to false. 

10 [0454] In addition to the prerequisite that necessary sets of measurement samples are available (vSyncPairs is true), 
the quality of the resulting correction terms forelock synchronization must be acceptable. The node is only allowed to 
join active communication (transition into NormalStatic sXa\.e), if the correction terms for both, rate and offset are below 
the configured limit settings {\vOffsetCorrection\ < pOffsetCorrectionOut and \ vMicroOverheadPerCycle\ < pRateCor- 
rectionOut). If one of the correction terms violates the limit settings, the node has to re-enter ListenStatic. The only 

15 exception to this rule is for the first time an offset correction value is available in IntegrationPCW slale. in this special 
case the correction value vOffsetCorrection may exceed the configured limit vOffsetCorrectionOut as long as I vOffsef- 
Correctionl < 2* pOffsetCorrectionOut. If this relaxed requirement can be met, the node remains in IntegrationPCW 
state, but does not transit into NormalStatic stale. After the first application of an offset correction term in Integration- 
PCW slate, the variable vOffsetOut Is set to true [vOtfsetOut is initialized with its default value {vOffsetOut Is set to 

20 false), when IntegrationPCW \s entered from InitSchedule). This variable is always evaluated, if a new offset correction 
term should be checked against the configured limit settings. Thus, the described exception is only made once, i.e., 
when the first offset correction term is available. 

[0455] The combination of all these checks ensures that the node only becomes an active transmitter if the local 
time base (including the cycle counter and the clock synchronization parameters) is consistent with the global time as 
25 represented by the majority of active sync nodes in the system. 

NormalStatic State 

[0456] As soon as the node that transmitted the first CAS symbol (resolving the potential access conflict and entering 
30 startup via coldstart path) and one additional node have entered Normal Static state, the startup phase is finished. In 
NormalStatic slate, all configured messages will be scheduled for transmission. This Includes all data frames as well 
as the sync frame. 

[0457] The message interface to the host is served and the error management is perfonned. 
35 PassiveStatic State 

[0458] In the PassiveStatic slale a node does not transmit any of its configured frames. Nevertheless, the node does 
not stop all activities. It continues clock synchronization, the reception of messages and the full support of the host 
interface. 

40 [0459] In addition, the PassiveStatic slale is used to support the 'listen only' protocol feature, where nodes are fully 
synchronized and receive all available frames (including receive buffer update), but do not transmit anything. This 
mode is indicated by vListenOnly, which can be set by the host in the SoftReset slale only. As soon as the host clears 
vLlstenOniy NormalStatic state is entered at the beginning of the next cycle. 

45 Startup States - FlexRay/byteflight Mode with pure dynamic segment 

Startup State Diagram 

[0460] Figure 55 shows a protocol state diagram - pure dynamic segment. 

50 



55 



98 



5/19/2010, EAST Version: 2.4.1.1 



EP 1 355 456 A1 



State 


State 


Direction 


Condition for Transition 


Transit 


from 






ion 


to 





Dli 


Lis ten 
Dynamic 


Normal 
Slave 


reception of a valid SOC at 

one of pChannels channels 

AND vListenOnly is false 


D2i 


Passive 
Dynamic 


reception of a valid SOC at 

^% ^ Mann « 7 o ^ a M q I c 

one or p\^nannej.s cnannej-s 
AND vListenOniy is true^^ 


D3i 


Normal 
Slave 


Listen 
Dynamic 


network idle time reached 
[vMacrotick== gdCycle- 
gdNetworkldleTime; decided on 
local timers) 


D4i 


SendSOC 


Normal 
Master 


transmission of the SOC 
finished 


D5i 


Normal 

Master 


SendSOC 


end of current cycle (derived 
from local cycle time) 


D6i 


Passive 
Dynamic 


Listen 
Dynamic 


network idle time reached 
{vMacrotick== gdCycle- 
gdNetworkldleTime; decided on 
local timers) 


D7i 


All 
States 


Soft 
Reset 


soft reset initiated 

(in the respective control 

register) 



Table 15: State Transitions and Corresponding Conditions for 



Execution 

" 'Listen-only' mode is an invalid configuration for a master node! 



SOCSend State 

40 [0461] A single node that has been configured as sync master (pMaster \s set) sends the SOC. With the end of the 
transmission the timers (of the receiver unit) are started according to the definitions in the media access chapter and 
the node enters NormalMaster state. 

[0462] When a node enters SOCSend state whiie a frame reception is ongoing the reception process is stopped. 
45 NormalMaster State 

[0463] The node sends and receives messages in the NormslMaster slaXe according to its configuration. Upon en- 
tering the NormalMaster state, i.e. after the transmission of the SOC, the startup phase is completed. The master node 
does not need any aclcnowiedgement from other nodes. 

50 

LIstenDynamIc State 

[0464] Aii slave nodes [pMaster\s false) wait in the ListenDynamic state for a valid SOC transmission. All connected 
channels are independently monitored. The transition into NormalSlaveand therefore the synchronization of both chan- 
55 nels to the master is done on reception of the first valid SOC. After initialization of the wait timers, both channels can 
operate asynchronously with respect to the required frame mini-slotting on each of the channels. 
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NormalSlave State 

[0465] Slave nodes synchronies to a valid SOC and transmit and receive messages in NormalSlave state according 

to tineir configuration. 

5 

PassiveDynamic State 

[0466] In PassiveDynamic a node does not transmit any of its configured frames. Still, the node does not stop all 
activities, but continues the synchronization to SOC (via ListenDynamlc sXale) and the reception of messages. 
10 [0467] The PassiveDynamic state is used to support the 'listen only' protocol feature, where the node Is fully syn- 
chronized and receives all available frames (including receive buffer update), but does not transmit anything. This 
mode is Indicated by vListenOnly, which can be set by the host in the SoftReset state only. As soon as the host clears 
vListenOnly, NormalSlave state is entered with beginning of the next cycle. 

[0468] Since the protocol controller still performs the transition to ListenDynamic state with every communication 
15 cycle, It is still synchronized to the master node. Therefore, the node is allowed to directly re-enter NormalSlave from 
ListenDynamic (with the begin of next cycle). If the host sets vListenOnly to false. 

Protocol Startup 

20 FlexRay Mode with Static Segment configured 

Startup Constraints 

[0469] 

25 

• The configuration must ensure that only nodes connected to all configured communication channels (pChannels 
= gChannels) are configured as sync nodes. Thus, In the absence of faults, the transmissions of a sync node that 
initiate the schedule synchronization are visible to every node. 

30 * It has to be ensured that all nodes Integrating to a communication schedule perfonn their clock synchronization 
synchronously. Specifically, this applies to the process of applying the clock correction terms (offset and rate). 
Since rate measurement phases take two cycles, it has to be guaranteed that there Is no spontaneous time shift 
in the schedule (due, perhaps to offset correction) while nodes are assessing their rate terms. Otherwise it cannot 
be prevented that offset correction harms the rate measurement process. 

35 

• The maximum single-cycle drift offset between two nodes operating with unsynchronized clocks must be a known 
system parameter. gdMaxDrift must be configured accordingly. 

• During startup, no update of message buffers is carried out. 

40 

General Startup Mechanism 
[0470] 

45 • A correctly configured communication controller enters the startup sequence after leaving the SoftReset by the 

transition to ListenStatic. 

• Upon leaving SoftReset, each node that is correctly configured as a sync node waits for a configurable time (listen- 
timeout; gdStartup) and monitors all connected pChannels channels for activity. 

50 

• If communication channel activity is detected on one of the configured channels while in ListenStatic, the listen- 
timeout is restarted. Every reception (including valid CAS symbols) different from a valid SYNCFramestartupEven 
causes this restart. 

55 • At the same time as the listen-timeout vdStartup Is started, a second timeout vdStartupNoise is started. This 
additional timeout is used to improve reliability of the startup procedure in the presence of noise. Since the timeout 
vdStartupNoisewonX be reset if channel activity is sensed, this timeout defines a fallback solution that guarantees 
that a node tries to start up the communication cluster even in the presence of noise. 
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As soon as either listen-timeout [vdStartup or vdStartupNoise) expires, a node that is configured to initiate the 
startup enters the coidstart phase (represented by ColdStartlCW and ColdStartPCW state sequence) and transmits 
an initial CAS. This is foilowed by the cyciic transmission of the configured sync frame on ali configured commu- 
nication channeis, pChannels. 

If two or more nodes simultaneously enter the coidstart phase, their CAS symbols do collide. However, the nodes 
themselves can resolve this scenario. This is due to the unambiguous assignment between nodes and fixed sync 
slots in the global communication schedule. 

During the first period of the coidstart phase {ColdStartlCW state) a sync node reacts very conservatively on 
network activity. This is due to the fact that during this period the detected transmission may have been initiated 
either by another node in coidstart phase or by a faulty node. In both cases the node In Co/dSfart/CI/V gives up 
performing the cluster startup and starts the process of integrating to an existing communication scheme. 

One cycle before the node in coidstart phase expects a response (sync frame reception) to its global schedule 
initialization attempt, the next phase {ColdStartPCW) is entered, in this phase the node expects sync frames to 
be sent out by other nodes in response to the initiated communication pattern. 

A node in coidstart phase continuously performs the regular clock synchronization, including the rate and offset 
measurements and the correction phase. 

It is required that the sync frames transmitted in response to the node in coidstart phase are consistent with the 
coidstart node with respect to 

• timing (rate and offset correction value must not exceed limit settings) 

• schedule position and cycle counter 

The node in Co/rfSfa/tPCI/V compares the observed communication pattern to its own view. Only if the majority 
(including one vote for the reference node itself) confirms the reference node does the node proceed with normal 
operation (i.e, enter NormalStatic). 

It is sufficient to receive just one valid SYNCFrames^a^up^yen (on one channel) in order to leave ListenStatic and 
start the clock initialization phase (represented by InitRate and InitSchedule states). 

The Clock initialization phase is part of the integration path. The Integration path additionally includes the confir- 
mation phase {IntegrationPCW state), which is entered after clock Initialization phase. 

Both the integration path and the coidstart path lead to the NormalStaticstate if communication startup is performed 
successfully. During the integration phase a node transmits neither sync frames nor data frames. In the coidstart 
phase a node transmits sync frames only. In the NormalStatic state all configured frames (sync frames and data 
frames) are transmitted. 

The sync node that transmits the valid SYNCFramestartupEven tl^^t causes other nodes to enter the clock initiali- 
zation phase Is treated as a reference. During clock Initialization phase each integrating node adjusts its 'clock 
rate' (only the macrotick "clock" is affected by this rate correction) according to the reference node's rate as meas- 
ured and derived in the InitRate state. All other nodes and their transmissions are ignored during the clock initial- 
ization phase. 

Each integrating node initializes its own cycle counter with the value received from the reference node and adjusts 
its schedule (cycle time) to the cycle time implied by the occurrence of the reference frame (InitScfiedule state). 

If the reference node does not support the integrating node through the whole clock initialization phase (e.g. the 
valid SYNCFramestortupOdd schedule alignment is missing), the integrating node re-enters ListenStatic after a 
timeout expires. 

Upon completion of the clock initialization phase, the integrating node's communication schedule Is synchronized 
to the observed reference schedule and it's clock synchronization algorithm is already initialized with a rate cor- 
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rection value. 

• Upon entering the confirmation pliase [IntegrationPCW state) the node continuously performs the regular clock 
synchronization. This includes both rate and offset measurement, and the correction phase aligned to the even/ 

5 odd cycle grid (see Section TBD). 

• During theconflrmatlon phase, the node checks Its local settings, which were initially derlvedfrom a single reference 
node, against the globally available Information with respect to 

10 * timing (rate and offset correction value must not exceed preset limits). 

If the reference node with Its clock representation Is nearto the maximum correctable deviation, it might happen 
(due to the additional propagation delay and certain topology characteristics) that the integrating node recog- 
nizes an offset correction value that exceeds the limit settings {pOffsetCorrectionOutj after first offset meas- 
urement, in this case a value up to twice the limit Is accepted and a further offset application phase together 

15 with a new measurement period is perfomned. After this sequence the value 

vOffsetCorrection must fulfill the limits 
{\vOffsetCorrection\ < 
pOffsetCoirectionOut) . 

20 • schedule position and cycle counter 

• Nodes in the IntegrationPCW staXe check the observed communication pattern against their own expected timing 

pattern, which is based on their own view of time. Only If the majority of sync frames observed confinn their view, 
does the node proceed with normal operation (enter the NoimalStatic state). 

25 

• if an integrating node has to return to the ListenStatic state (due to a detected fault during the clock initialization 
phase or the confirmation phase), its rate correction value is reset to its default value. The node does not Imme- 
diately use the same reference node for the next Integration attempt. The node Ignores the former reference node 
until the timeout vdCycleWithHistory exp\res or an attempt to Integrate using a different reference node also falls. 

30 This timeout covers a whole communication cycle and enables the possibility that another node (if available) could 

become the new reference. The fallback mechanism Is the same for all nodes, regardless of whetherthey are sync 
nodes or not. 

FlexRay/bytef light Mode with Pure Dynamic Segment 

35 

[0471] 

• A correctly configured sync master communication controller (pMaster\s true) enters the startup sequence via the 
transition from SoftReset lo NormalMaster. 

40 

• Only one node should be configured as the sync master node, which must send a SOC symbol on all gChannels 
channels. For the sync master node pChannels must be equal to gChannels. 

• A correctly configured slave node communication controller (pMaster \s false) enters the startup sequence via the 
45 transition from SoftReset lo ListenDynamic. 

• Ail slave nodes synchronize to the SOC transmitted by the sync master node. If that node does not start, the 

system does not start up. 

50 • Slave nodes start their communication cycle on both channels with the reception of the first valid SOC on one of 
the pC/ia/ine/s channels. 

Startup Exampies - Networlt in FlexRay iVIode with Pure Static Configuration 

55 [0472] For ail startup sequences described In this chapter the assumption Is made that the correction terms for clock 
synchronization exactly match the limit settings of the quality assessment criterion (see Section TBD). Therefore, the 
node is allowed to proceed directly Into normal operation [ListenStatic state) after having performed the offset meas- 
urement, correction phase, and regular rate measurement phase the first time. 
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Startup without Collisions 

[0473] Figure 56 shows a collision-free Startup, 

[0474] Tine scenario illustrated in Figure 56 depicts three nodes with two of them configured to initiate the startup 
5 actively (sync nodes A and B). Node C does is not configured to schedule any sync frames and therefore is not allowed 
to enter ColdStartlCW. The first cycle counter value received by nodes B and C is in the sync frame sent by node A 
and It Is even. 

[0475] Node A enters ColdStartlCW and transmits the Initial CAS before any other node. Triggered by the reception 
of the CAS, node B restarts Its listen-timeout vdStartup. With the first sync frame sent by node A all other nodes enter 

10 InitRate. At this point Node A becomes the reference node {vSyncRef=3) and the measurement phase for initial rate 
correction term Is started. The next occurrence of node A's sync frame stops the rate measurement phase. Nodes B 
and C transit to InitSchedule where they directly apply the determined rate correction term to their local clock rate (1. 
e. to their local macrotick generation unit). In addition, the actual schedule position is determined based on the reference 
frame ID, and the micro- and macrotick timers are synchronized to the SOF of the received sync frame. 

'5 [0476] Nodes B and C follow the current schedule until cycle end and then transition into the IntegrationPCW slate. 
Still these nodes behave passively, i.e., they do not participate the communication schedule with their own frames. 
After one complete rate measurement period (2 cycles) and the corresponding offset measurement and correction 
phase (during the second cycle) , the sync node B Is allowed to enter nonnal operation . The plausibility checks evaluates 
In the IntegrationPCW state are passed because on the reception of the reference sync frame vValidSyncCount Is 

20 incremented, while vInvalidSyncCount remains unchanged. Consequently, with the start of next cycle, node B enters 
NormalStatic and starts to transmit messages according to its configuration. On reception of the sync frame pair sent 
by another node (node B), which is synchronized to its own, the node that initially sent the CAS (node A) then enters 
NormalStatic at the start of next communication cycle (after a whole rate measurement period has been concluded). 
In NormalStatic all configured frames are scheduled for transmission. As soon as the node that initially sent the CAS 

25 and one other node have entered the NormalStatic state, the startup phase is concluded. 

[0477] Node C enters NormalStatic in the same cycle as node A, as soon as it performs the regular rate measurement 
phase based on 2 (or more) pairs of corresponding sync frames {vSyncPairs is true). 

Startup with initial Collision 

30 

[0478] Figure 57 shows a Startup with a collision on the CAS symbol. 

[0479] The scenario illustrated in Figure 57 depicts three nodes with all of them configured to initiate the startup 
actively (sync nodes). A collision during startup results when two sync nodes leave SoffResef state at the same, or 
nearly the same time. In this case, two nodes (nodes A and B) enter CoWSrarf/Cl/Vsimultaneously and send their initial 

35 CAS al Ihe same, or nearly the same time. Both nodes are then prepared to send their first sync frame. The node with 
the sync frame having the lower identifier sends its frame first (node B; fFramelD= 1). On reception of this sync frame, 
the other node (node A), which currently resides in the ColdStartlCW state, returns to ListenStatic and waits for the 
next valid SYNCFramestaitupEveti' The figure depicts the case where a node A integrates in the sixth cycle after the 
cycle in which the collision occurred. 

40 [0480] Depending on the network topology and channel characteristics, non-sync nodes may detect activity but no 
valid CAS because of the collision, while others may detect a valid CAS (because the topology prevents collisions). 
For both cases the reaction Is the same, since valid CAS symbols are treated like network activity that cannot be 
Interpreted. The nodes remain In ListenStatic and wait for the occurrence of a valid SYNCFramestaitupEven' 

45 Startup with Nodes Failed Due to the Plausibility Checit 

[0481] Figure 58 shows a Startup with a plausibility check in IntegrationPCW laWedi. 

[0482] The scenario illustrated in Figure 58 depicts nodes B and C starting integration to the reference node (node 
A). While nodes B and 0 are in the IntegrationPCW state the reception of the sync frame transmitted by the reference 

50 node fails at both nodes. Thus, the plausibility check at both nodes fails, too. At the end of this cycle both nodes have 
to re-enter the L/sfenSfaf/c state. Since vRefSync\s different from 0 (vfle/Sync=3), the first sync frame from the former 
reference node (node A) is ignored. Because no other sync frame occurs during gdCycleWithHistory, vRefSync Is 
cleared at the end of this cycle. With the next occurrence of the sync frame sent by node A {vRefSync\s set to 3 again), 
node B and C start another integration attempt. Via the Integration path, both nodes finally synchronize on timing of 

55 node A. Meanwhile, Node A remains in ColdStartPCW state for the entire period because It does not detect a valid 
response. 
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Sync Master Failure and Reintegration 
FlexRay Mode with Static Segment Configured 
s [0483] 

• Cluster synciironization is maintained by the global clock synchronization mechanism that Is executed locally by 
each node based on Its received sync frames. This mechanism Is robust In the sense that, with limits, cluster 
synchronism Is maintained even when faults reduce the number of sync frames upon which the mechanism relies. 

10 However, the protocol does not support any autonomous handling or countermeasures to be used to dynamically 

correct a loss of synchronization. This situation requires host Intervention and the affected node has to be reinte- 
grated via the SoftReset stale with all the subsequent steps that commence upon transitioning to the ListenStatic 
state. 

15 • Nodes that reintegrate after having withdrawn from communication from a running communication cluster behave 
the same as nodes that Integrate the first time. All nodes that do not start the network by themselves (via Cold- 
StartlCW) have to take the Integration path (InitRate, InitSchedule, and IntegrationPCW states). 

Pure Dynamic Networic 

20 

[0484] 

• The sync master node cannot detect that its SOC transmission has failed. Thus, It continues normal operation until 
it is forced into the SoftReset state by the host, 

25 

• All slave nodes either starting up Initially or reintegrating, enter ListenDynamic artd wait until next SOC reception, 
which triggers their transition Into the NormalSlave state. 

Supplements 

30 

[0485] Chapter 14 'System Constants, Parameters and Variables' 
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Name 


Description 


Range /Value 


Uni 

t 










gdMaxDrift 


maximum drift offset 
between two node that 
operate with 
unsynchronized clocks 
over one 

communication cycle 




MT 


gdStartup 


upper limit for the 
listen-timeout in 
ListenStatic state 
(before a sync node 
is allowed to become 
a coldstart node) ; 
this is not a 
configuration 
parameter ! 


gdStartup = 

gdCycls+gdMaxDzi 

ft 


MT 


gdlnitialCheckWi 
ndow 


period for which a 
node remain in 
ColdStartlCW state, 
if no incident causes 
the transition into 

UM9 cri<*^ c a u w 

beforehand; 
this is not a 
configuration 
parameter 


3* gdCycie + 
gdSlot 


MT 


gdPlausibili tyCh 
eckWindow 


plausibility check 
interval applied in 
ColdStartPCW and 
IntegrationPCW state 


Version 5 
Solution : 

gdCycle - 

gdNe tworkldleTim 

e 


MT 










pdStartupNoise 


upper limit for the 
listen-timeout with 
noise in S state 
given as a multiple 
of crdStartup 






pdCycleWithHisto 
ry 


upper limit for 
timeout that covers a 

period, which is 
large enough that any 
periodic transmission 
that complies to the 
global communication 
schedule is visible 
for an unsynchronized 
node at least once; 


gdStartup 


MT 
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Name 


Description 


Range /Value 


Uni 
t 












this is not a 
configuration 
parameter 






pMaster 


denotes that the node 
is configured as the 
sync master in 

mode with pure 
dynamic segment 


Boo2ean 




pdini tRa teMEarly 


early reception 
window for initial 


pRa teCorrectionO 
ut 


mT 


ri^Tn ihlSA i-t^JJTT ^i-a 


for initial rate 
measurement 


pRateCorrectionO 
ut 


mT 


pSyn cUode 


denotes that the node 
is a sync node (sync 
slot configured; 
connected to 
aChannels) 


Boolean 












vListenOnly 


denotes that the node 
is not allowed to 
transmit 


Boolean 




vColaStaTzlnhitti 
t 


denotes that the node 
is not allowed to 
enter coldstart path 


Boolean 




vdstartup 


listen-timeout 
(counter) in 
jjiszenszacic state 


[0. .gdStartup] 


MT 


vdStartupNoise 


list en- timeout 
(counter) with noise 
in ListenStatic state 


[0.. 

pdStartupNoise * 

gdStartup] 


MT 


vNolse 


denotes that 
coldstart path has 

been entered due to 
the expiration of 
pdStartupWoise 


Boolean 




vColdStartCount 


counter for number of 
cycles /transitions 
for which the node 
has been in the 
coldstart path 


[0. .gColdStartMa 

X] 
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Name 


Description 


Range/Value 


Uni 
t 










vdlnitialCheckWi 
ndow 


timer for the period 
for which a node 
remain in 

ColdStartlCW state, 
if no incident causes 
the transition into 
Lis ten Static 

V> o "F n T" o H a n H 


[0. .gdlnitialChe 
ckWindow] 


MT 


vdin itRat eMEa rly 


timer for early 
reception window for 
initial rate 
measurement 


[0.. 

pdlnitRa teMEarly 

] 


mT 


vdini tRa teMLa te 


timer for late 
reception window for 
initial rate 
measurement 


[0. . 

pdini tRa t eMLa te] 


mT 


vin vali dSyn cCoun 
t 


counter for invalid 
SYNCFramestar-upPcw 
decisions during 
gdPlausibilityCheckWi 
ndow 


[0-.31] 




vValidSyncCoun t 


counter for valid 
SYNCFramestarcupPCH 
decisions per slot 
during 

gdPlausibilityCheckWi 
ndow 


[0.. 

cSyn cNodeMa x ] 


— 


vOffsetOut 


denotes that the 
application of the 
extended limit 
setting for the 
offset correction 
terra check is 
prohibited 


Boolean 




vdCycleWi thHist o 
ry 


timeout counter that 
covers a period, 
which is large enough 
that any periodic 
transmission that 
complies to the 
global communication 
schedule is visible 
for an unsynchronized 
node at least once 


[0. . 

pdCycleWi thHisto 
ry] 


MT 


vRefSvnc 


contains the 


[0-. 1023] 
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Name 


Description 


Range /Value 


Uni 
t 


5 










10 




identifier of the 
sync frame, which has 
been originally used 
to enter the 
■i ntporation oath 






15 
20 


vSyncPairs 


denotes that enough 
corresponding sync 
pairs were available 
for a rate 
measurement with at 
least two reference 
points; prerequisite 
for transition into 
NormalStstic state 


Boolean 





Chapter 11 

25 Error Handling and Diagnosis 

[0486] Version 5 Solution: The entire Error Handling and Diagnosis section Is specific to FPGA V5. Subsequent 
versions of the protocol will Ikely use a different error management scheme. 

30 Error iVIanagement 

Overall Error Processing 

[0487] This chapter describes the error handling mechanisms of FlexRay protocol that are intended to ensure the 
35 proper operation of Ihe protocol under error conditions. The overall philosophy behind the error management strategy 
is "never-give-up" until a predefined criticality of error states Is reached. The error detection and management mech- 
anisms attempt to avoid faulty behavior of the protocol In the presence of errors. The FlexRay protocol specification 
and the design of the FlexRay hardware (communication controller, bus guardian, bus driver, etc.) are assumed to be 
fault-free. 

40 [0488] Four error severity levels are defined, ranging from SO through S3. The definition of the severity level Is based 
on the severity of the failure that the error could cause In the system. The en'or severity levels are summarized In Table 
16. 

[0489] The error severity level directly Influences the protocol behavior as described In the table (CC, CC to API, 
Result, BG, Comment). The FlexRay error handling matches the overall protocol state machine (see Figure 59). The 
45 currently active severity level shall be taken Into account at each protocol decision. 



Table 16: 



Error Severity Levels 


Name 


Severity 
Level 


Behavior 


Normal 


SO 


CC: full operation. CC to API: no warning, no error flags active. Result: Normal 
operation. BG: remains synchronized 


Warning 


SI 


CC: full operation. CO to API: flag for detected error. Result: Maintain normal 
operation, provide error Indication to host. BG: Remains synchronized. Comment: 
No Immediate effect on protocol operation. The host is Informed of the errorconditlon 
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Table 16: (continued) 





Error Severity Leveis 


5 


Name 


Severity 

Level 


Behavior 


10 


Error 


S2 


CC: reduced operation, CC to API: flag for detected error. Result: The node stops 
transmitting frames, but received frames are still processed. Clock synchronization 
mechanism continues based on received frames. BG: Remains synchronized. 
Comment: CC self rescue is allowed. The fault causing the error was non-fatal. The 
CO will not act as a coldstart node for the wake-up procedure. 


15 


Fatal Error 


S3 


CC: Operation halted. All signals to the bus driver and bus guardian are placed in 
defined states. CC to API: flag for detected error. Interaction with host must still be 
possible. Result: The node stops transmitting and receiving frames. BG: BG enters 
FallSllent state due to loss of ARM signal. The BG disables transmissions until reset 
by host. Comment: CC self rescue not allowed. The fault causing the error was fatal. 
A reset from the host is required to resume operation. 



[0490] Figure 59 shows the protocol (error) state machine. After startup a FlexRay CO starts operation in 

20 

• Normal Static state, if the node is configured for pure static or mixed static/dynamic operation and at least one 
other CC is active and In the Normal Static protocol state. 



• Listen Only state, if the node Is configured to listen only during full operation and does not actively send any frames 
(see PassiveStatic state, Section TBD). 

• Normal IVIaster state, if the node is configured for pure dynamic or byteflight compatible operation, the node is 
currently acting as SOC master (sending SOC symbols), and is actively sending frames. 

• Normal Slave mode, if the node is configured for pure dynamic or byteflight operation, the node is not acting as 
SOC master (is not sending SOC symbols), but is actively sending frames. 

[0491] The protocol (error) state machine shall remain in the Normal Static, Listen Only, Normal Master or Normal 
Slave state as long as no errors are detected (remain in error severity SO) or if any detected errors have error severity 

SI (see Table 16), 

[0492] The detection of any error with an error severity of S2 shall cause the protocol state machine to enter the 
Passive state where the CC is not allowed to send frames but where all protocol mechanisms (frame reception, clock 
synchronization, etc.) remain active. 

[0493] The detection of any error with an error severity of S3 shall cause the protocol state machine to enter the 
Error state, where no frame transmission is allowed and all protocol operation ceases. The CC can only return to normal 
operation after being reset by the host, (see Table 16). 

[0494] The protocol (error) state shall be Error while at least one S3 severity error is active, otherwise it shall be 

Passive while at least one S2 severity error is active, otherwise it shall be in Normal Static (Listen Only, Normal IVIaster, 
Normal Slave). In other words, the error level of the communication controller shall be the error level of the most severe 
error that is currently active. 

Error Detection 

[0495] The intended "never-give-up" strategy of FlexRay is achieved by several mechanisms for controlling / moni- 
toring the operation. These mechanisms continue to operate even in the presence of faults. 

[0496] Table 1 7 lists the errorf lags and en-or counters of the FlexRay protocol . The following sections provide detailed 
description of the various flags and counters. 
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Table 1 7: 



Error Flags and Error Counters 


Error Flags 


Abbreviation 


Channel Status and Error Vector 


CSEV 


Frame Status and Error Vector 


FSEV 


Error Counters 


Abbreviation 


Valid Sync Frame Counter 


VSFC 


Invalid Sync Frame ID Counter 


ISIC 


Invalid Sync Frame Cycle Counter 


ISCC 


Missing Rate Measurement Counter 


MRMC 


Missing Offset Measurement Counter 


MOMC 


Clocl< Correction Failed Counter 


CCFC 



20 Error Fiags 

Frame Status and Error Vector (FSEV) 

[0497] A FlexRay Communications Controller shall provide two channel-specific Frame Status and Error Vectors 

25 (FSEV's) for each communication buffer. CC's that are only capable of single channel communication need only provide 
an FSEV the channel that it supports. A dual channel controller needs to provide two buffers to allow a host using a 
"select first" stylo buffer to understand the communication on the "non-selected" communication channel. If the buffer 
is operating in a channel-specific mode the information on the other channel is redundant. The FSEV allows the host 
to determine the status of communications associated with the buffer. Each vector consists of six bits that provide 

30 indications of various error or normal conditions that can occur during the reception of a frame. Table 18 lists the 
contents of the vectors. 



Table 18: 



Frame Status and Error Vector 


Name 


Checic Setsi2 


Static 
Segment 


Dynamic 
Segment 


Bit Coding Error/CRC Error 


CodingOrCRCError 


Applies 


Applies 


Slot Mismatch 


SiotMlsmatchError 


Applies 


Applies 


Cycle Counter Mismatch 


CycieMlsmatch Error 


Applies 




Missing Frame 


MissingFrameErroris 


Applies 




Null Frame 


NullFrameDetected 


Applies 




Length Mismatch (length code different 
from real length, real length different from 
expected length) 


LengthMlsmatchError 


Applies 


Applies 



' ^ Refer to Table 1 9 for definitions of the c)ieci< set conditions. 
Not yet defined In Frame Cfieck Section 

50 

[0498] Table 1 9 gives the sets of checks that make up the various error conditions that are reported in the FSEV and 
CSEV. 
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CodingOrCRCError 
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X 
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X 
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T 


X 


F 
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X 
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X 


SlocMlsmacchError 


T 


T 


T 




X 


X 


X 


X 


X 


CycleMismacchError 


T ' T 


T 


X 


X 


X 


X 


X 


F 


MissingFrameError 


X 


X 


X 


X 


X 


X 


X 


X 


X 



30 



Nullf rameDetected 


T 


T 


T 


X 


X 


X 


X 


F 


X 


LengthMismatchError 


T 


T 


T 


X 


X 


X 


r 


X 


X 


T 


T 


T 


X 


T 


F 


X 


X 


X 



Table 19: FSEV/CSEV Error Check Conditions 



[0499] Each static FlexRay frame buffer has corresponding FSEV's. The FSEV is reset (all flags set to 0) during 
configuration ("Sofl Reset" state) and is not updated before the CC is synchronized within other devices in the networl< 
("Normal" protocol state). 

[0500] The FSEV is updated at the time a frame has been completely received. In case no frame is received, the 
FSEV is updated upon reaching the end of the slot. 

[0501] The Null Frame Detection condition has an error severity of SO. All of the other conditions reported in the 
FSEV have an error severity level of S1 . 

[0502] Error Handling and diagnosis during startup Is described in Section "Startup Status Vector (SSV), Startup 
Status interrupt Enable Vector (SSIEV)". 

Channel Status and Error Vector 

[0503] A FiexRay Communication Controller shall provide a channel-specific Channel Status and Error Vector 
(CSEV) for each supported communication channel. The CSEV reports the status of ail frames received on the com- 
munication channel, even if the frames do not have an explicit receive buffer. This implies that a host can get information 
about errors that may have occurred on the channel In slots that have no associated Frame Status and Error Vector. 
Table 20 lists the contents of the CSEV. 
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Table 20: 



Channel Status and En-or Vector 


Name 


Check Setsi4 


Static 
Segment 


Dynamic 
Segment 


Null Frame 


Null FrameDetecled 


Applies 




Empty Slot 


MissingFrameError 


Applies 




Bit Coding /CRC Error 


CodingOrCRCError 


Applies 




Length Mismatch 


LengthMlsmatchError 


Applies 


Applies 


Slot Mismatch 


SlotMlsmatch Error 


Applies 


Applies 


Cycle Counter Mismatch 


CycleMismatchError 


Applies 





15 Refer to Table 19 for definitions of the cfieck set conditions. 

[0504] The data in the CSEV is available to the host via the Communication Host interface (CiHi). The flags in the 
CSEV may be reset by the host. The CSEV reports the aggregate status of ail frames on the communication channel. 
More specifically, the bit corresponding to a particular condition wiii be set if any frame has experienced that condition 
^° since the CSEV has been reset by the host. Errors that occur more than once will not receive any special indication. 

The reception of a frame with no errors shall not clear the flags in the CSEV. 

[0505] The Null Frame condition has an error severity of SO. Ail of the other conditions reported in the CSEV have 
an error severity level of S1 . 

Error Counters 

[0506] The following sections define the various error counters used for FiexRay error diagnosis and management, 
in all cases the counters are not allowed to be incremented past their maximum value, i.e,. the counters shall not "wrap 
around" bacl< to zero, but rather shall remain at their maximum value. 

30 

Valid Sync Frame Counter (VSFC) 

[0507] The Valid Sync Frame Counter counts the number of correctly received sync frames in one communication 
cycle For the purposes of this counter, a sync frame that is received on both channels only counts as a single valid 
■^^ sync frame. The counter shall start at zero at the beginning of the communication cycle. The VSFC from the previous 
communication cycle shall be available to the host until the end of the current cycle, at which time It shall be replaced 
by the VSFC of the current cycle. 

[0508] Error Handling Level: An error of severity S1 shall be detected if the Valid Sync Frame Counter exceeds 1 6 
at the end of the communication cycle. An error of severity S1 state shall also be detected if the Valid Sync Frame 
Counter is zero at the end of the communication cycle. 

Invalid Sync Frame ID Counter (ISIC] 

[0509] The Invalid Sync Frame ID Counter counts the number of sync frames which are received with a slot mismatch 
error. The counter shall start at zero at the beginning of the communication cycle. The ISIC from the previous commu- 
nication cycle shall be available to the host until the end of the current cycle, at which time it shall be replaced by the 
ISIC of the current cycle. 

[051 0] Error Handling Level: An error of severity S2 shall be detected if the Invalid Sync Frame ID Counter is greater 
than the Valid Sync Frame ID Counter at the end of the communication cycle. This condition indicates that the local 
50 cc disagrees with the majority of sync frame senders with respect to the current Slot ID. 

Invalid Sync Frame Cycle Counter (ISCC) 

[0511] The Invalid Sync Frame Cycle Counter counts the number of sync frames which are received with a cycle 
counter mismatch. The counter shall start at zero at the beginning of the communication cycle. The ISCC from the 
previous communication cycle shall be available to the host until the end of the current cycle, at which time it shall be 
replaced by the ISCC of the current cycle. 
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[0512] Error Handling Level: An error of severity S2 shall be detected if the Invalid Sync Frame Cycle Counter Is 
greater than the Valid Sync Frame Counter at the end of the communication cycle. This condition indicates that the 
local CO disagrees with the majority of sync frame senders with respect to the current cycle count. 

5 Missing Rate Measurement Counter (MRMC) 

[0513] The Missing Rate Measurement Counter counts the number of consecutive even/odd cycle pairs for which It 
was not possible to compute a clock rate correction term. This counter shall be set to zero when the node begins 
normal operation. It shall be Incremented by one if no rate correction tenn can be computed at the end of an odd 
10 communication cycle. This would occur If the node has not received any matching pairs of even/odd cycle sync frames 
with the same Frame ID. If a rate correction term can be computed the CC shall reset this counter to zero at the end 
of the odd communication cycle. 

[0514] Error Handling Level: An error of severity S1 shall be detected If the MRMC Is greater than zero but less 
than the parameter gMaxWithoutRate. An error of severity S2 shall be detected if the MRMC Is greater than or equal 

15 to gMaxWithoutRate. 

Missing Offset Measurement Counter (MOMC) 

[0515] The Missing Offset Measurement Counter counts the number of consecutive even/odd cycle pairs for which 
20 It was not possible to compute a clock offset correction term. This counter shall be set to zero when the node begins 
normal operation. It shall be Incremented by one if no offset correction term can be computed at the end of an odd 
communication cycle. This would occur If the node has not received any sync frames during an odd communication 
cycle. If an offset correction term can be computed the CC shall reset this counter to zero at the end of the odd com- 
munication cycle. 

25 [0516] Error Handling Level: An error of severity 81 shall be detected if the MOMC is greater than zero but less 
than the parameter gMaxWithoutoffset. An error of severity S2 shall be detected If the MOMC is greater than or eq ual 
to gMaxWithoutoffset. 

Clock Correction Failed Counter (CCFC) 

30 

[0517] The Clock Correction Failed Counter is used to limit the number of cycles that a node that is currently expe- 
riencing a clock offset or rate correction failure can remain at an error severity level of S2 (which allows self recovery) 
before being forced to an error severity level of S3 (where recovery Is only possible via host Intervention). This counter 

shall be set to zero when a node begins normal operation. It shall be Incremented by one at the end of any odd 
35 communication cycle where either the Offset Correction Failed or Rate Correction Failed errors are active (see Sections 
"Offset Correction Failed" and "Rate Correction Failed" below). It is assumed that the inability to compute a rate or 
offset correction term does not affect that term's Correction Failed status. The CCFC shall be reset to zero at the end 
of an odd communication cycle if neither the Offset Correction Failed nor the Rate Correction Failed errors are active. 
[0518] Error Handling Level: An error of severity S3 shall be detected if the CCFC is greater than or equal to the 
40 parameter gMaxWithoutClockCorrection. 

Offset Correction Failed 

[0519] At the end of an odd communication cycle if the clock synchronization mechanism calculates an offset cor- 

45 rection term which Is outside of the green region (refer to the Clock Synchronization chapter) the host shall be consid- 
ered to have detected an Offset Correction Failed error. The Offset Correction Error shall remain active until the node 
computes an offset correction term that is in the green area, at which time the node shall consider the Offset Correction 
Failed error inactive. Note that this implies that the inability to compute an offset correction term does not change the 
Offset Correction Failed status. The status can only change If an offset correction term is actually computed, 

50 [0520] Error Handling Level: The detection of an active Offset Correction Failed error shall have an error severity 
level of S2. The detection of this error also starts Incrementing the Clock Con'ectlon Failed counter; see Section "Clock 
Correction Failed (CCFC)" for details. 

Rate Correction Failed 

55 

[0521] At the end of an odd communication cycle if the clock synchronization mechanism calculates a rate correction 
term which is outside of the green region (refer to the Clock Synchronization chapter) the host shall be considered to 
have detected a Rate Correction Failed error. The Rate Correction Error shall remain active until the node computes 
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a rate correction term that is in the green area, at which time the node shaii consider the Rate Correction Faiied error 
inactive. Note that this implies that the inability to compute a rate correction term does not change the Rate Correction 
Faiied status. The status can only change if a rate correction term Is actuaiiy computed. 

[0522] Error Handling Level: The detection of an active Rate Correction Failed error shaii have an error severity 
5 ievei of S2. The detection of this error also starts incrementing the Clock Con-ection Failed counter; see Section "Clock 
Correction Failed (CCFC)" for details. 

SOC Early (pure dynamic and bytef light modes) 

10 [0523] This error Is active if the end of a correct SOC occurs before gdCycleMin. This condition Is reset after a cycle 
of duration greater than gdCydeMin Is observed. 
[0524] Error Handling Level: The error has a severity level of S1 . 

SOC Lost (pure dynamic and byteflight modes) 

15 

[0525] This error is active if the end of a valid SOC does not occur before gdCycleMax. This error condition Is reset 
with the reception of the next valid SOC. 

[0526] Error Handling Level: This error has a severity level of S2. 
20 Illegal Pulse Error (ILLPIF) for pure dynamic and byteflight modes 
[0527] This error flag is set if 

• gdCycleMin has not expired since the last correct (valid) SOC symbol and a sequence of logic "0" with a duration 
25 of between 21 * gdBit and 29 * gdBit or a duration of more than 31 * gdBit has been received, OR 

• gdCycleMin has expired since the last correct (valid) SOC symbol and some bus activity was recognized other 
than a valid SOC symbol. 

30 [0528] Error Handling Level: This error has a severity level of S2. Reset to SO as soon as the next SOC is received. 
Diagnosis - Interface to Host 

Interrupt Status Vector (ISV), Interrupt Enable Vector (ISEV) 

35 

[0529] The FlexRay Communication Controller provides error status information to the host via an Interrupt Status 
Vector (ISV). Each of the error detection mechanisms described above has an associated bit In the iSV, Ail of the 
Individual flags of the Channel Status and Error Vector are mapped Into the ISV, as well as all Individual warning/error 
conditions described above. There Is one additional bit in the ISV to signal a receive buffer error. The bits of the ISV 

40 are set to one if the condition described above becomes true. 

[0530] The FlexRay CC provides at least one Interrupt line to the application. Each of the Interrupt sources In the 
Interrupt Status Vector (ISV) shall be enabled separately by an Interrupt Status Enable Vector (ISEV) which Is set by 
the host. The ISV will be updated regardless of the contents of the ISEV. The ISEV simply enables the access of the 
interrupt source to the Interrupt line. 

45 [0531] An additional interrupt Enable Vector is used to set interrupt conditions for any of the Frame Status Error 
Vectors, which exist for each "malibox/buffer" of a FlexRay CC. This Frame Status Interrupt Enable Vector (FSiEV) 
enables the interrupt signaling to the host according to the set bits within this enable register, e.g. only CRC errors of 
any mailbox/buffer cause an interrupt. 

[0532] The following table summarizes the relations among the error flags of the CSEV, the single error flags to 
50 evaluate the error counters, the signal bit for the FSEV as well as the byteflight specific error flags. 



ISV_0 


7 


6 


5 


4 


3 


2 


1 


0 


CRC 


SLOT 


COUNT 


LENGTH 


FSEV 


SOC Early 


SOC Lost 


ILLPIF 



• CRC: signals a detected Bit Codlng/CRC error within the CSEV 
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SLOT: signals a detected Slot Mismatch within the CSEV 

COUNT; Signals a detected Cycle Counter Mismatch within the CSEV 

LENGTH: signals a detected Length Mismatch Error within the CSEV 

FSEV: Indicates that In at least one FSEV the frame status error vector was modified 

SOC Early: signals the byteflight / pure dynamic SOC Early error. See Section "SOC Early (pure dynamic and 
bytefllght modes)". 

SCO Lost: signals the byteflight/ pure dynamic SOC Lost error. See Section "SOC Lost (pure dynamic and byteflight 

modes)". 

ILLPIF: signals the byteflight specific Illegal Pulse Error (ILLPIF). See Section "Illegal Pulse Error (ILLPIF) for pure 
dynamic and byteflight modes". 



ISV_1 


15 


14 


13 


12 


11 


10 


9 


8 




MRMC 


MOMC 


Offset Failed 


Rate Failed 


Max CCFC 


Max SYNC 


Zero SYNC 



MRMC: signals that no rate correction term could be computed because no pairs of (even/odd) sync frames were 
received. See Section "Missing Rate Measurement Counter (MRMC)". 

MOMC: signals that no offset correction term could be computed because no sync frame was received In an odd 
cycle. See Section "Missing Offset Measurement Counter (MOMC)". 

Offset Failed: signals that the calculated offset correction term was not within the green area of the clock correction 
algorithm. See Section "Offset Correction Failed". 

Rate Failed: signals that the calculated rate correction term was not within the green area of the clock correction. 
See Section "Rate Correction Failed", 



Max CCFC: The Clock Correction Failed Counter reached the defined maximum of gMaxWithoutClockCorrection 
odd communication cycles with one or both of the clock correction terms outside of the green area. See Section 
"Clock Correction Failed Counter (CCFC)". 

MaxSYNC: signals that more than the maximum of 1 6 valid sync frames were received in the last communication 
cycle (VSFC > 16). See Section "Valid Sync Frame Counter (VSFC)". 

ZeroSYNC: signals that no valid sync frames were received In the last communication cycle (Valld_Syncframe ID 
Count = 0). See Section "Valid Sync Frame Counter (VSFC)". 



ISV_2 


23 


22 


21 


20 


19 


18 


17 


16 














Minority VSCC 


Minority VSIC 



• Minority VSCC: signals that the local CC is within the minority of CCs with respect to the view of the current 
Cycle^Counter of the network. See Section "Invalid Sync Frame Cycle Counter (ISCC)". 

• Minority VSIC: signals that the local CC is within the minority of CCs with respect to the view of the current Slot_ID 
of the network. See Section "Invalid Sync Frame ID Counter (ISIC)". 

[0533] The following table shows the Interrupt Status Enable Vector (ISEV) for the corresponding signals in ISV_0 

to ISV 2: 
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ISEV_0 


7 


6 


5 


4 


3 


2 


1 


0 


ENABLE 


ENABLE 


ENABLE 


ENABLE 


ENABLE 


ENABLE 


ENABLE 


ENABLE 


CRC 


SLOT 


COUNT 


LENGTH 


FSEV 


SOC Early 


SOC Lost 


ILLPIF 



ISEV. 


J 














15 


14 


13 


12 


11 


10 


9 


8 




ENABLE 


ENABLE 


ENABLE 


ENABLE 


ENABLE 


ENABLE 


ENABLE 




MRMG 


MOMC 


Offset Failed 


Rate Failed 


iVIax CCFC 


iVIax SYNC 


Zero SYNC 



ISEV_2 


23 


22 


21 


20 


19 


18 


17 


16 














ENABLE iVIinority VSCC 


ENABLE IWIinority VSiC 



[0534] A logical ONE enables the error condition to be a source to trigger the interrupt line to the host. A logical 
ZERO disables Ihe signaling of that error condition to the host. The ISV will always represent the current status re- 
gardless of the value in the ISEV. 
25 [0535] The following table shows the Frame Status Interrupt Enable Vector (FSIEV) for the corresponding signals in 
each mailbox's/buffer's Frame Status Vector; This means that, e.g., any CRC error of any mailbox/buffer will cause an 
interrupt signal to the host if the corresponding Enable bit in FSIEV is set. 



FSIEV 


7 


6 


5 


4 


3 


2 


1 


0 






ENABLE 


ENABLE 


ENABLE 


ENABLE 


ENABLE 


ENABLE 






CRC/Coding 


SLOT 


CYCLE 


MISSING 


NULL 


LENGHT 








MISIVIATCH 


MISIVIATCH 




FRAME 


MISMATCH 



[0536] A logical ONE enables the signal to be a source to trigger the interrupt line to the host. A logical ZERO disables 
the signaling to the host. The FSEV will always represent the current status of the buffer regardless of the value in the 
FSIEV. 

Startup Status Vector (SSV), Startup Status Interrupt Enable Vector (SSIEV) 

[0537] Each of the interrupt sources in the Startup Status Vector shall be enabled separately by Startup Status 

Interrupt Enable Vector which is set by the application. The SSV will be updated regardless of the values of the SSIEV. 
The SSIEV enables the access of the interrupt source to the interrupt line. The following signals (error conditions) out 
of startup shall be summarized in SSV. 



50 



SSV 


7 


6 


5 


4 


3 


2 


1 


0 








coldst art max 


Plaus 


prefsync 


coldst art path 


pstart upnoise 



• Coldstart max: The maximum number of allowed retries of a Cold Starting CC is reached. The CC is no longer 

allowed to initiate a cold start sequence, 

• Plaus: The plausibility check of the local CC within the startup sequence failed. 

• Coldstart Path: The normal state of the local CC was reached via the coldstart path. (This indicates that the local 
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CC was the node that started the network.) 

• Pstartupnoise: The coldstart path within the local CC has been entered due to the expiration of pStartupNoise. 

[0538] The following table shows the Startup Status interrupt Enable Vector for the corresponding startup status 
vector. 



SSVE 


7 


6 


5 


4 


3 


2 


1 


0 








ENABLE coldst 
art max 


ENABLE Plaus 


ENABLE 
prefsync 


ENABLE coldst 
art path 


ENABLE pstart 
upnolse 
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Error counters 

0539] The previously described error counters shall be available to the host: 

Valid Sync Frame Counter (VSFC) - see Section "Valid Sync Frame Counter (VSFC)" 
invalid Sync Frame ID Counter (ISiC) - see Section "Invalid Sync Frame ID Counter (ISIC)" 
invalid Sync Frame Cycle Counter (iSCC) - see Section "Invalid Sync Frame Cycle Counter (iSCC)" 
iVIissing Rate Measurement Counter (iVIRIVIC) - see Section "Missing Rate Measurement Counter (MRMC)" 
Missing Offset Measurement Counter (MOMC) - see Section "Missing Offset Measurement Counter (MOMC)" 
Clock Correction Failed Counter (CCFC) - see Section "Clock Correction Failed Counter (CCFC)" 
Error Severity Level 

[0540] The current error severity level (SO through S3) shall be made available to the host. 
Chapter 12 

35 

Host Interface Requirements 
Purpose 

[0541] This chapter contains the requirements for the FlexRay communication Controller-Host Interface (CHI). 
Interface to higher layers 

[0542] Tine CHI is the interface between the higher layers and the data link layer. 

[0543] Tine term CHI suggests that a FlexRay node consists always of two primary hardware elements, which are 

connected via the CHI: 

• FlexRay communication controller 

^° • Host in.the form of a general CPU or DSP 

[0544] For the following It Is assumed that the CHI Is above the data link layer. A transport layer or a fault tolerant 
communication layer (FTCom) would be above the CHI. 

Controller-Host Interface Mechanisms 

[0545] Tine layers above the CHI dictate what mechanisms the CHI must contain. To adequately support the layers 
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above it, the CHI must provide meciianisms that: 

• De coupie the host from the stringent timing requirements of the FiexRay protocoi 
5 • Enable the host to provide the controller with 

• Controiier configuration data 

• Frame data to be transmitted 

10 

• Bus Guardian status 

• External clock correction parameters 

15 • Control the controller states, e.g. soft-reset, deactivate (force in passive state, sleep) 

• Enable the controller to provide host with 

• Controiier status information which Is not iinlcedto specific frames or slots, e.g. current protocoi state, controiier 
20 awaWe or sleeping, If the controller is active SOC master, etc. 

• Received frame data including the frame identifier, sync bit, frame length, header CRC, cycle counter, message 
identifier, data field, possible acltnowiedgement bits 

25 Version 5 Solution: Acknowledgment bits are not supported In V5 

[0546] 

• Frame status information, e.g. if a valid frame or a null frame was received. If an coding error or CRC error was 
30 detected in a specific slot 

• Infomnation about the current cycle, e.g. if the SOC was normal or alarm symbol (pure dynamic mode), number of 
correctly received SYNC frames 

35 » Information on global time, namely current cycle counter, macrotick, most recently calculated clock offset and rate 
correction term 

• Filter or demultiplex received frames based on Cycle counter and / or Message ID, namely store frames with 
the same ID but different Cycle counter and / or l\/lessage ID in different receive buffers 

40 

• Provide host with mechanisms to: 

• Trigger Interrupts on specific Communication Controller conditions 
45 • Retrieve diagnostic infomnation 

[0547] The CHI shall be Implemented as a 16 bit aligned address/data bus to support l\^otorola's PPC and Star12 

micro controllers, and Texas Instruments' TMS470 family. 

[0548] Version 5 Solution: Texas Instruments TMS470 compatibility Is not expected for FPGA V5. 
50 [0549] Designated configuration data should be protected from unintended manipulation by the host, by allowing 
changes only in a specific Communication Controller mode (e.g. soft reset state). 
[0550] All interrupt flags should be individually maskable. 

[0551] A FIFO message area should be provided for receiving frames that do not have a dedicated receive buffer. 
It should support a maskable rejection filter with the following characteristics: 

55 

• It can be applied to the following fields of a received frame: 

• Frame ID 
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• Message ID 

• Cycle Counter 

5 • It can be altered by the host at any time using designated mechanisms. 

• It Is applied to both channels simultaneously. 

[0552] All information contained In a valid received frame should be stored in the designated receive buffer (or FIFO) 
10 except the frame CRC. The receive buffer should contain a field Indicating the channel on which the stored frame was 
received. If the header of the received frame does not match any of the configured filters, the frame should be discarded 
without storing any frame data, 

[0553] if no frame or a corrupted frame is received in a slot, the buffer contents prior to the reception should not be 
deleted or overwritten, if a null frame is received in a slot, the buffer contents prior to the reception should be overwritten 
15 if so configured. The discrepancy to the configured frame should be signaled to the host using a suitable bit in the 
corresponding buffer status register 

[0554] When the host forces the CC Into soft reset, the status and error registers should keep their data unchanged 
until the soft reset Is released. 

20 Controller Host Interface 

Controller Status Registers 

[0555] This section enumerates the registers supported by the Communication Controller to provide the host with 
25 status Infonnatlon regarding the operation of the controller 

Module Version Register 

[0556] 

30 

• 8 bit read only register to hold the FlexRay Protocol Implementation Version (05h for FPGA V5) 
Current Cycle Counter Value 

35 [0557] 

• 6 bit; will be incremented by CC; shall be readable by host. 
Current Maciotick Value 

40 

[0558] 

• 1 6 bit; will be Incremented by CC and reset at start of cycle; shall be readable by host. 
45 Rate Correction V^lue 

[0559] 

• Current (cycle related) rate correction value applied by clock sync: 8 bit; shall be readable by host. 

50 

Offset Correction Value 
[0560] 

55 * Current (cycle related) offset correction value applied by clock sync: 8 bit; shall be readable by host. 
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Valid Sync Frames Counter 
[0561] 

5 • 5-bit counter indicating the number of valid Sync Frames received in the previous cycle. The counter is only updated 
at the end of the static segment and can be read by the host. 

Invalid Sync Frame ID Counter 

10 [0562] 

• 5-bit counter indicating the number of invalid Sync Frames received with a slot mismatch error in the previous 
cycle. The counter is only updated at the end of the static segment and can be read by the host. (FPGA V5) 

15 Invalid Sync Frame Cycle Counter 

[0563] 

• 5-bit counter indicating the number of Invalid Sync Frames received with a cycle counter mismatch error in the 
20 previous cycle. The counter is only updated at the end of the static segment and can be read by the host. (FPGA V5) 

Missing Rate Measurement Counter 

[0564] 

25 

• 5-bit counter is incremented by one if no rate con-ection can be perfonned because no pairs of (even/odd) Sync 
Frames were received. The counter is reset by the CC after successful rate correction. The counter is not incre- 
mented once it reaches maximum value (63). 

30 Missing Offset Measurement Counter 

[0565] 

• 5-bit counter is incremented by one if no offset correction can be performed because no Sync Frames were received 
35 in an odd cycle. The counter is reset by the CC after successful offset correction. The counter is not incremented 

once it reaches maximum value (63). 

Error Handling Level 
40 [0566] 

• 2 bits, indicating the current error handling level. 

[0567] Version 5 Solution: Error IHandling Level is a characteristic of the V5 Error iVIanagement strategy and may 
45 not apply if the V5 only Error Management strategy is not retained in V6. 

Startup Status Vector 

[0568] The CC shall provide a Startup Status Vector with following status flags: 

50 

• Coldstart max reached (see Section "Cold Start ly/lax") 

• Plausibility check failed 

55 • Normal state entered via coldstart path 

• Coldstart path has been entered due to the expiration of pStartupNoise 
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Configuration and Control Registers 

[0569] This section enumerates the registers supported by the Communication Controlier(CC) to allow the host to 

controi the operation of the CC. 

5 

Module Configuration Register 
[0570] 8 bit; to hold following control bits: 
10 . Soft Reset 

• Master select (only modifiable In soft reset) 

• Master Alarm 

15 

• Sleep Acknowledge 

• Sleep Request 

20 • bytefllght Compatibility mode (only modifiable in soft reset) 

• External SOC Trigger Acceptance (only modifiable In soft reset) 
FIFO Size 

25 

[0571] 

• Number of FIFO mailbox receive buffers: 5 bits (FPGA V5); may be modified only In soft reset. 
30 Timing Parameters 

[0572] 

• TCR1 , TCR2, TCR3: three 8 bit registers; may be modified only In soft reset. The timing parameters apply to both 

35 channels. 

Clocic Prescaler 

[0573] The clock prescaler register may be modified only in soft reset. It consists of the following three fields: 

40 

• Bit Rate Index, 4 bits 

• Sample Clock Prescaler, 4 bits 

45 • Samples per bit, 2 bits (8 or 10 samples; 01 h = 8, 1 0h = 10 samples) 
HAax. Osciilator Drift 

[0574] Maximum allowed drift for the oscillator 

50 

• 8 bits, value in macroticks, configurable only In soft reset. (Comment: gdStartup Is derived Internally.) 
Giitch Sampies 

55 [0575] 

• 3 bits; configurable in soft reset with the number of samples to be filtered out by the receiver. 
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Bit Duration 
[0576] 

5 • Microticks per bit: 6 bits; may be modified only in soft reset. 
Nominai iVlacrotici< Length 
[0577] 

10 

• Microticks per macrotick: 8 bits; may be modified oniy in soft reset. 
Bus Guardian IViicroticks 

15 [0578] Tine microtick duration, whicli is provided to tine bus guardian. 

• 4 bits; multiples of tine CC microtick, configurable only in soft reset. 
Static Slot Lengtli 

20 

[0579] 

• Macroticks per slot: 8 bits; may be modified only in soft reset. 
25 Static Data Frame Length 

[0580] 

• Data length for static frames, in words: 7 bits; may be modified only in soft reset. 

30 

Number of Static Slots 
[0581] 

35 » Number of static slots in a cycle; 10 bits; may be modified only in soft reset. 
Cycle Length 
[0582] 

40 

• Macroticks per cycle: 1 6 bits; may be modified only in soft reset. 
Max. Cycle Length Deviation 

45 [0583] 

• 6 bits; maximum acceptable deviation (+/-) of pure dynamic cycle length in microticks; may be modified only in 

soft reset. 

50 Cycle Counter Max. 
[0584] 

• Maximum Cycle Counter value before it is reset: 6 bits; may be modified only in soft reset. 

55 
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Network Idle Time 
[0585] 

5 • Number of Macroticks: 8 bits; may be modified only in soft reset. 
Start of Latest Transmit 
[0586] 

10 

• i\^ax. macrotici< value allowed before inhibiting new frame transmissions forthe cycle: 16 bit; may be modified only 
in soft reset. 

Time Window for External SOC Trigger 

15 

[0587] 

• Start of time window in pure dynamic mode for external SOC trigger acceptance; Number of i\^acroticks: 16 bit; 
may be modified only In soft reset. 

20 

External Clock Correction (see Clock Sync Chapter) 
[0588] 
25 * 8 bits 

Offset Correction Warning (see Clock Sync Chapter) 
External Rate Correction (see Clock Sync Chapter) 

30 

[0589] 

• 8 bits 

35 Cluster Drift Damping (see Clock Sync Chapter) 
[0590] 

• 4 bits; cluster bit damping, configurable only in soft reset. 

40 

Timer Interrupt Configuration Registers 

[0591] The CC shall provide two Timer interrupt Configuration Registers for configurable timer interrupts. Each shall 
contain three fields: 

45 

• Cycle Set - A 9 bit register Is used to specify in which set of cycles the interrupt shall occur. It consists of two fields, 
the Base Cycle [b] and the Cycle Repetition [c]. The set of cycle numbers where the inten^upt is to generated is 
determined from these two fields using the fonnuia 

50 

b + n*2^) 



(n = 0,1,2...): 

55 • Base Cycle [b] - A 6 bit cycle number used to identify the initial value for generating the cycle set 

• Cycle Repetition [c] - A 3 bit value used to determine a constant repetition factor to be added to the base, cycle 
(c=0...6). 
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[0592] Comment: The maximum cycle counter value must be one less than a power of two. 

• Macrotick Offset - This 1 6-bit value is the macrotick offset from the beginning of the cycle where the interrupt Is to 
occur. The interrupt occurs at this offset for each cycle in the Interrupt Cycle Set. 

5 

Transmitter Generated Padding 

[0593] In the CC a configuration switch decides whether the transmitter may add missing data bytes If the configured 
frame data length exceeds the length of the buffer data field. 

10 

• Disabled (logical '0') by default, may be Enabled (logical '1') only In soft reset. 

Update Receive Buffers from Null Frame - switch 

15 [0594] This configuration switch determines whether the data Is copied out of a received Null Frame into the mailbox 
buffer or not. The configuration switch applies to all mailbox receive buffers of the CC. 

• Disabled (logical '0') by default, may be Enabled (logical '1') only In soft reset. 
20 Cold Start IVlax 

[0595] The value In this register determines the maximum number of cycles a cold starting node is permitted to try 
to start up the network without receiving any valid response from another node. If the value Is '0' the CC Is not allowed 

to start up the communication. 

25 

• 8 bit; configurable only in soft reset, 
n/iax. Without Rate Correction 

30 [0596] 

• 5 bits; This register corresponds to the variable gMaxWithoutRate. If gMaxWithoutRate consecutive cycles tran- 
spire without performing rate correction then host notification occurs via Interrupt. The register can be configured 
only In soft reset. 

35 

[0597] Version 5 Solution: After FPGA V5, this register and IVlax Without Offset Correction will be replaced with a 

single register, IVlax Without Clock Correction. 

Il/lax. Without Offset Correction 

40 

[0598] 

• 5 bits, This register corresponds to the variable gMaxWithoutOffset. If fif/Maxl/WfAioi/fOffsef consecutive cycles tran- 
spire without performing rate correction then host notification occurs via interrupt. The register can be configured 

45 only In soft reset. 

[0599] Version 5 Solution: After FPGA V5, this register and Max Without Rate Correction will be replaced with a 

single register, IVlax Without Clock Correction. 

50 |\/|ax. Without Clocl< Correction 
[0600] 

• 5 bit, configurable with the maximum acceptable number of cycles without perfonning rate correction. The register 
S5 can be configured only In soft reset. If the Clock Correction Failed Counter equals Max. Without Clock correction 

(maxwithoutclockcorrectlon), an Interrupt will be raised. 
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Startup Status Interrupt Enable Vector 

[0601] The CC shall provide a Startup Status Interrupt Enable Vector for Enabling (logical '1') or Disabling (logical 
'0') interrupts corresponding to the following events: 

5 

• Coldstart max reached 

• Plausibility check failed 

10 • Normal state entered via coldstart path 

• Coldstart path entered due to the expiration of pStartupNoise 
Buffer Control Register 

15 

[0602] The host access to the mailbox message buffers is controlled by the use of a Buffer Control Register. This 
control register has one byte for each mailbox buffer. 



Table 21 : 



20 


IVIailbox Buffer Control Register Fields 




Control Flag 


Bits 


Tx Buffer 


Rx Buffer 


FIFO 
Buffer 


Comment 


25 


Reserved 


1 




Reserved 


1 




CFG* 


1 


'1' = Transmit Buffer 


'0' = Receive Buffer 


'0' 


Message Buffer 

Configurati on Bit 


30 


CFG_SR' 


1 


'1' = Mailbox Buffer 
and the associated 
filter can be 
configured only 
during Soft Reset. 


'1' = Buffer and the 
associated filter can 
be configured only 
during Soft Reset. 




'0' = Mailbox Buffer 
and the associated 
filtercan beconfigured 
during nonnal 
operation, (not for 
FPGA V5) 


35 
40 
45 


IFLG 


1 


'1' = buffer not 
updated, '0' = buffer 
updated; Host 
explicitly resets the 
1 FLG when the buffer 
is ready for transmit, 
IFLG is set by the CC 
after transmission 
has been completed 
and the host may 
access the buffer for 
writing next message. 


'1' = buffer updated 
(valid), '0' = not 
updated; Host has to 
explicitly clear the 
IFLG. 




Interrupt Status Flag 




lENA 


1 


'1' = Interrupt enabled 


'1' = Interrupt enabled 




IFLG Interrupt Enable 


50 


ABTRQ 


1 


'1' = Abort request; 
Message will be 
aborted at next DCT if 
transmission has not 
been started before 
next DCT. 






Abort Request (not for 
FPGA V5) 


55 


ABTAK 


1 


'1' = Message has 

been aborted. 






Abort Acknowledge 
(not for FPGAV5) 



* The host can modify the control flags CFG and CFG_SR only during soft reset. 
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Table 21 : (continued) 





Mailbox Buffer Control Register Fields 


5 


Control Flag 


Bits 


Tx Buffer 


Rx Buffer 


FIFO 
Buffer 


Comment 


10 


LOCK 


1 


'1' = locl<, '0' = release 


'1' = lock, 
'0' = release 




Message Buffer Lock. 
A locked buffer is 
visible in the 
correspondi ng 
mailbox window. 



Mailbox Message Buffers 

15 [0603] The communication controller has to provide 32 configurable mailbox message buffers for data communication 
with a frame length of up to 32 data bytes. (Values are valid for FPGA V5.) The mailbox buffers can be configured to 
be used as transmit, dedicated receive or FIFO receive buffers. 

[0604] Each buffer has to include the complete frame header and data field, and shall not include the frame CRC. 
The CC must provide suitable mechanisms to grant a secure access to the DPRAM buffers. Using e.g. a locking 
20 mechanism, eltherthe CC orthe host may get access to one particular mailbox buffer. In order to prevent data mismatch 
a window access scheme may be used (e.g. one window for the active transmit buffer, one for the active dedicated 
receive buffer, and one for the active FIFO receive buffer). Only one single buffer of one type may be locked and visible 
to the host at the same time. 

[0605] There are mailboxes, which can be configured during Soft Reset only while the others can be reconfigured 
25 during runtime. 

Transmit Buffers 

[0606] A portion of message buffers can be configured as transmit buffers. The set of transmit buffers shall be con- 
so tiguous in the register map starting at buffer 32 (for FPGA V5) and ending before the first receive buffer. 

[0607] For the static segment, fixed configured transmit mailboxes shall be used. The frame ID, Sync Bit, DLC and 
header CRC are written only once during soft reset and can not be changed by the host during runtime (workaround 
for FPGAV5). 

[0608] There is one explicit mailbox (buffer #32 for FPGAV5), which must be configured to hold the transmitted Sync 
35 frame of a node, If It transmits one, and which can be reconfigured only in soft reset. This ensures that for Sync Frames, 
the Sync Frame ID, Sync Bit, DLC and the corresponding header CRC can be changed only during soft reset (FPGA 
V5 and V6). 

[0609] If more than one transmit buffer Is configured with the same frame ID, cycle counter and channel, the first 
matching buffer will be sent out by the CC. 
40 [061 0] For transmit frames in the dynamic part reconf igurable mailboxes can be used. The frame ID and the corre- 
sponding DLC can be reconfigured during runtime (FPGA V5 and V6). 

[0611] The CC does not calculate the transmit header CRC (FPGA V5 and V6). It must be provided by the host for 
all transmitted frames. 

[061 2] The length field In all messages (static and dynamic) reflects the actual physical frame data length as defined 
45 In the frame format. The CC may use mailbox transmit buffer structures shorter than the actual (physical) data frame 
length In the static segment. In this case, the CC will generate padding bytes to ensure that frames have proper physical 
length. However, this capability must be enabled via configuration (see Section 'Transmitter Generated Padding"). The 
padding pattern shall be logical ZERO. The padding function shall apply only to frames to be transmitted in the static 
part. In the dynamic part no frame will be transmitted If the data field In the buffer Is shorter than the configured data 
50 length. 

Null Frame transmission 

[0613] If the host does not update a transmit message for the static part before transmission time (see IFLG in Table 
55 21), the frame will be transmitted containing the current buffer contents consisting of the previously transmitted data. 
The CC will set the Null Frame Bit in the frame header to Indicate that the transmitted message Is a Null Frame. (For 
FPGA V5 this Indication will be one single bit). Null Frames are not transmitted In the dynamic part. 
[0614] It Is configurable whether data from received Null Frames shall be copied Into the CC receive mailboxes (see 
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Section "Update Receive Buffers from Nuii Frame - switch"). This configuration appiies to aii receive maiiboxes. It 
cannot be appiied to the mailboxes individually. 

Receive Buffers 

5 

[0615] A portion of the CC's message buffers can be configured as dedicated receive buffers. The set of dedicated 
receive buffers shall be contiguous in the register map starting after the last transmit buffer and ending before the first 

Fi FO receive buffer. 

[061 6] Tlie CC transfers valid received messages from the serial receive message buffer to the dedicated receive 
10 buffer with the matching filter configuration. 

FIFO Receive Buffers 

[0617] A portion of the CC's message buffers can be configured as FIFO receive buffers. The set of FIFO receive 
15 buffers shall be contiguous in the register map starting after the last dedicated receive buffer and ending with the last 
message buffer. 

[061 8] The CC transfers valid received messages from the serial receive message buffer to the FI FO receive buffer 
if there is no matching dedicated receive buffer and the header is not rejected by the FIFO Rejection filter (see Section 
"FIFO Filtering"). 

20 

Frame Status and Error Vector 

[0619] in addition to the actual transmitted or received data, each message buffer must possess a Frame Status and 
Error Vector The Frame Status and Error Vector contains six bits which are summarized in the following table: 

25 

Table 22: 



Frame Status and Error Vector 


Status/Error Flag 


Bits 


Tx Buffer 


Rx Buffer 


FIFO Buffer 


Null Frame 


1 


Null Frame transmitted 


Null Frame received (static 

part) 


Null Frame received 


Empty Slot 


1 




No bus traffic detected 
(static part) 




Bit Coding/CRC Error 


1 




Error detected (bit coding, 
header or frame CRC, in 
static part) 




Length IVIIsmatch 


1 




Length IVIIsmatch detected 
(static part) 




Slot Mismatch 


1 




Slot Mismatch detected 




Cycle Counter Mismatch 


1 




Cycle Counter Mismatch 
detected (static part) 





[0620] Version 5 Solution: For FPGA V5 one vector shall be defined for each channel. 

[0621] The vector content is updated at the end of the slot (defined by the configured Frame ID) by the communication 
controller and can be checked by the host. 

[0622] In searching for Frame Id matches, searching commences with the receive buffer adjacent to the last transmit 
buffer. It proceeds incrementally through the remaining receive buffers. If more than one receive buffer holds the same 
frame ID, the error vector is updated in the first matching buffer. 

[0623] The flags are set if one of the listed errors is detected by the communication controller. The host can check 
the vector any time. An interrupt will be triggered by the CC if the corresponding interrupt enable bit in the General 

Enable Register is set (see below). 
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Filtering and Masking 
Definitions 
5 Message Filtering 

[0624] Message filtering is done by checi<ing specific fieids In a message against corresponding configuration con- 
stants in the buffer, with the stipuiation that message is only processed further if the required matches occur. Otherwise, 
it is discarded. IVIessages are filtered on the following message fields: 

10 

• Channel Number 

• Frame Id 

15 t Cycle Counter 

• ly^essage Id 
Message Filter Mask 

20 

[0625] Masking of message filters means that some (parts) of the filtering parameters may be configured to be dis- 
regarded (set to "don't care"). 

Filtering Mechanisms 

25 

[0626] The filtering mechanisms described below are applied differently for receive and transmit message buffers 

• Receive buffer; In order to store a message the filters for channel Id, and cycle counter must match. In addition, 
depending on a configuration bit either the Frame Id (configuration bit = "0") or the Message Id (configuration bit 

30 = "1") must match (but not both). 

• Transmit buffer: A message will be transmitted in the time slot corresponding to the frame ID on the configured 
channel(s) if the cycle counter matches the configured cycle filter value. 

35 Channel Filtering 

[0627] There is a Channel Filtering field (2 bits) associated with each buffer. It serves as a filter for a receive message 
buffer, and as a control field for a transmit message buffer. 
[0628] Depending on the buffer configuration 

40 

• Receive buffer: received frames are stored if they are received on all the specified in the Channel Filtering Field. 
Other filtering criteria must also be met. 

• Transmit buffer: the content of the buffer is transmitted only on the channels specified in the Channel Filtering Field 
45 when the Cycle Counter Filtering and Frame Id Filtering criteria are also met. 



Table 23: 



Channel Filtering Configuration 


Config. bit 
A 


Config. bit 
B 


Tx Buffer Transmit 
frame 


Rx Buffer Store valid Rx frame 


1 


1 


on both channels 


received on channel A or B (not for V5) 


1 


0 


on channel A 


received on channel A 


0 


1 


on channel B 


received on channel B 


0 


0 


no transmission 


ignore frame 
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Frame ID Filtering 

[0629] Every Transmit and Receive mailbox message buffer contains a frame ID. This frame ID is used differently 

for receive and transmit message buffers 

5 

• Receive message buffers: A received message is stored in the first receive message buffer where the received 
frame ID matches the receive mailbox frame ID, provided the other receive filtering criteria are also met. if i\^essage 
id filtering is being used, this filter is not applied. 

• ForTransmit buffers the frame ID in the buffer is used to determine the appropriate slot for the message transmis- 
10 sion. The frame will be transmitted in the time slot corresponding to the frame ID, provided the channel and cycle 

counter criteria are also met. 

Cycle Counter Filtering 

15 [0630] Cycle Counter Filtering is based on the notion of a Cycle Set. For filtering purposes, a match occurs if any 
one of the elements of the set is matched. 

• Cycle Set - A 9 bit register is used to specify which cycle numbers are elements of the set. It consists of two fields, 
the Base Cycle [b] and the Cycle Repetition [c]. The set of cycle numbers belonging to the set determined from 

20 these two fields using the formula 

b + n*2^) 

25 (n = 0,1,2...): 

• Base Cycle [b] - A 6 bit cycle number used to identify the initial value for generating the cycle set 

• Cycle Repetition [c] - A 3 bit value used to detennine a constant repetition factor to be added to the base cycle (c 
30 =0...6). 

[0631] The operation of the filtering mechanism depends on the configuration of the buffer: 

• Receive buffer: The received message is stored only if tfie received cycle counter matches an element of the 
35 buffer's Cycle Sel. Channel, Frame Id and IVIessage Id criteria must also be met, 

• Transmit buffer: the content of the buffer is transmitted when an element of the Cycle Set matches the current 
cycle counter and the frame ID matches the slot counter value. 

40 Message ID Filtering 

[0632] IVIessage ID filtering applies only for receive message buffers. For message ID filtering the first two data bytes 
out of the receive buffer are used. The received frame will be stored in the configured receive buffer if the message 
ID, channel and cycle counter match. The frame ID will be stored in the buffer, but ignored for filtering. 
45 [0633] There is no message ID filtering used for frame transmission. 

FIFO Filtering 

[0634] For FIFO filtering there is one Rejection Filter and one Rejection Filter Mask available. Each register consists 
50 of 36 bits for channel (2 bits), frame ID (12 bits), cycle counter (6 bits), and message ID (16 bits). The two registers 
can be reconfigured in soft reset as well as during runtime. 

[0635] A received frame will be stored in the next free FIFO buffer if the channel, frame ID, cyclecounter, and message 
ID are not rejected by the configured reject and mask reject filter and if there is no matching dedicated receive buffer 
in the mailbox. 

55 

General Interrupts 

[0636] In general, interrupts provide a close link to the protocol timing as they are triggered almost immediately when 
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an error is detected by the controller, a frame is received or transmitted, or a configured timer interrupt is activated. 
Tlnis aliows the host to react very quicl<ly on specific error conditions, timers and events. On the other hand too many 
interrupts can cause the host to miss deadlines required for the application. Therefore it must be possible to disable/ 
enable interrupts, separately and as a whole. 
[0637] An interrupt may be triggered when 

• A status bit is set 



• A counter exceeds a specific value 

• A timer reaches a configured value. 

[0638] Tracking status and generating Interrupts when a status change occurs are two Independent tasks. Regardless 

of whether an interrupt is enabled, or not, the corresponding status should be tracked 

[0639] At least one hardware interrupt line shall be available to signal an interrupt to the host. 

General Interrupt Register 

[0640] The communication controller has to provide a General Interrupt and Error Indication Register. 

Table 24: 



General Interrupt Register 


f^anoral Intern int Plan 
uici ici di iiiLciiu|JL nidy 


Bits 




f^hannol 

Ol ICtI II ici 


Bit Coding/CRC Error 




Error detected (bit coding, header or frame 
CRC)) 


A 


Slot Mismatch 




Slot Mismatch detected 


A 


Cycle Counter IVIismatch 




Cycle Counter Mismatch detected 


A 


Length IVIismatch 




Length Mismatch detected 


A 


SOC NormaM^ /Collision Avoidance^^ symbol 




SOC Normal or Collision Avoidance symbol 
detected 


A 


SOC Alarm symbol" 




SOC Alarm symbol detected 


A 


SOC Too Early 




SOC received before qdCycleMin 


A 


SOC Lost 




SOC not received before gdCycleMax 


A 










Bit Coding/CRC Error 




Error detected (bit coding, header or frame 
CRC) 


B 


Slot Mismatch 




Slot Mismatch detected 


B 


Cycle Counter Mismatch 




Cycle Counter Mismatch detected 


B 


Length Mismatch 




Length Mismatch detected 


B 


SOC Normal / Collision Avoidance symbol 




SOC Normal symbol detected 


B 


SOC Alarm symbol 




SOC Alarm symbol detected 


B 


SOC Too Early 




SOC received before gdCycleMin 


B 


SOC Lost 




SOC not received before qdCycleMax 


B 



30 



The SOC Normal symbol is only used on byteflight and pure dynamic FleKRay configurations. 

Tlie Collision Avoidance symbol is used only used on pure static and mixed (static and dynamic) FlexRay configurations. 
" The SOC Alarm symbol Is only used on bytefllgtit and pure dynamic FlexRay configurations. 

[0641] The flags are set when the communication controller detects one of the listed errors or SOC symbols. The 
host can check the vector. The communication controller has to provide a General Error Interrupt, which will be triggered 
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when any of the flags is set, provided the corresponding interrupt is enabled. For this purpose, the CC has to provide 
for each general interrupt indication flag a General Interrupt Enable flag. 

General Interrupt Enable Register 

[0642] 



Table 25: 



General Interrupt Enable Register 


General Interrupt Enable Flag 


Bits 


Channel 


Bit Coding/CRC Error 




A 


Slot Mismatch 




A 

A 


Cycle Counter Mismatch 




A 

A 


Length Mismatch 




A 


SOC Normal / Collision Avoidance symbol 




A 


SOC Alarm symbol 




A 


SOC Too Early 




A 


oL.'O L051 




A 
A 








Bit Coding/CRC Error 




B 


Slot Mismatch 




B 


Cycle Counter Mismatch 




B 


Length Mismatch 




B 


SOC Normal / Collision Avoidance symbol 




B 


SOC Alarm symbol 




B 


SOC Too Early 




B 


SOC Lost 




B 









[0643] The settings in the General Interrupt Enable Register determine which status changes in the General Interrupt 
40 Register will result in interrupts. The Bit Coding/CRC Error Slot Mismatch, Cycle Counter Mismatch and Length Mis- 
match flags also Enable/Disable the corresponding interrupts in the Frame Status and Error Vector of the receive 
buffers. 

Receive Interrupt Status Register 

45 

[0644] The communication controller has to provide a Receive Interrupt Status Register to indicate the reception of 

a valid frame (stored In one of the mailbox buffers), a SOC, or an optical diagnosis signal (when using an optical 
physical layer). The flags are set by the CC when a corresponding event occurs. If enabled, an interrupt is pending 
while one of the bits is set. 
50 [0645] Following read-only bits shall readable by host: 

• Receive Interrupt Flag 

• Receive FIFO Not Empty Interrupt Flag 

55 

• Receive FIFO Overrun Interrupt Flag 

• SOC Normal Inten-upt Flag 
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• SOC Alarm Interrupt Flag 

• Optical Diagnosis Flag 

5 Receive Interrupt Enable Register 

[0646] The communication controller has to provide a Receive Interrupt Enable Register to enable each of the Re- 
ceive Interrupt Status Register flags separately. 

10 Indication of bus events (not for FPGA V5) 

[0647] The communication controller by way of additional output signals indicates the following events: 



Table 26: 



Bus Event Indication 


Event 




Description 


SOC Normal symbol detected on bus 




SET_SOCNIF 


SOC Alami detected on bus 




SET_SOCAIF 








Correct message was received which may be copied 
into a receive buffer 




SET RCVMSG, even if message is not copied Into 
any buffer (in case no adequate receive buffer is 

configured) 


Frame Error detected. One of following checks 
failed: vCheckldlebeforeFram e, vCheckCoding, 

vCheckActiveDuringFr ame, vCheckCRC, 
vCheckldleAfterFrame , vCheckBodyLength 




SET_ERRIF 


Slot mismatch detected. The check vCheckSlotID 

failed. 




SET_SLMM 



[0648] The exact attribution of events to interrupt vectors or lines is described in the specifications in the respective 
communication controller implementation. 

[0649] In order to enable error monitoring in a star node the communication controllershall provide four output signals 

with the setting of internal status flags indicated by means of a pulse. 

[0650] The following figure shows which internal events should be indicated extemally. 

[0651] Figure 60 shows SLMM, ERR, ROK and SYNC signals. 

[0652] If an internal event is indicated, the corresponding signai lias to be switched to the active state for a defined 
time, In order to generate a logicai "1" signai with a duration of at least 50 ns. 

[0653] Tine SLMM signal confirms the reception of a frame with a correct format and correct CRC, even if the frame 

identifier deviates from the slot counter value at reception time. 
[0654] Tine ERR signal indicates an error as described above. 

[0655] Tine ROK signal indicates that a correct frame has been received even if the message was not copied into a 
buffer in the communication controller 

[0656] The SOC signal confimns that a valid SOC symbol (Normal or Alarm) has been received or sent. It can be 
used to trigger timers or to start synchronized software tasks with every SOC. 

[0657] Every communication controller should be able to generate at least the signals ERR, ROK and SOC. 
Chapter 13 

Bus Guardian Interface 

[0658] Tine decentralized bus guardian protects the communication channel against illegal medium access by a 
communication controiler. This section describes the expected bus guardian behavior with a focus on the scheduling 
scheme and the relationship between bus guardian and communication controiler. Cycle- and clock synchronization 
of the bus guardian to the communication controller are described and a subset of the bus guardian configuration 
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parameters is specified. 
Bus Guardian Operation ii/lodes 
5 Normai 

[0659] in Normai mode the bus guardian is configured and the sclieduler is Initiaiized. in nonnal mode the bus guard- 
ing function is enabled, with the BG ailowing access to the bus during configured communication siots and disailowing 
it at ail other times. Any bus guardian error resuits In a faii back to FailSiient mode, causing an error flag wili be set 
10 and an interrupt to be generated (If enabled). 

FaiiSiient 

[0660] In FallSllent mode bus access Is disabled. The FailSiient mode Is used at start-up and as a faiibaci< In error 
15 cases. FailSiient mode may only be left by an SPi command from the Host. 

Bypass 

[0661] The Bypass mode is used for pure dynamic FiexRay configurations and bytefiight compatlbie configurations. 
20 For testing purposes like transceiver evaluation the Bypass mode also is entered if a dedicated test Input of the BG is 
HIGH. 

[0662] Bus access is permanently enabled. The Bypass mode may be entered or left by an SPI command. SPI 
commands overrule the setting of the dedicated test input. 

25 WaiceUp 

[0663] In WakeUp mode the bus access is enabled and the bus guardian does not checkf or transmission- or reception 
errors. An ARM trigger during WakeUp mode will cause an arming error and the BG will enter the FailSiient mode. At 
the end of the wake-up period the Host has to Initiate a transition from WakeUp mode to FailSiient mode before the 
30 CC may start communicating by sending the initial ARIVI trigger to the BG. 

[0664] WakeUp mode is Intended for the initial wakeup only, not for sending wakeup messages during normal op- 
eration. 

StopCom 

35 

[0665] To support the StopCom service, a communication controller stops sending messages at the end of the com- 
munication cycle and enters the ShutdownRequest state. The bus guardian supports this service by entering the Stop- 
Com mode. 

[0666] In StopCom mode the bus guardian continues to control the bus access in the same manner as in Normal 
40 mode and also continues to monitor the ARI\^ signal. If the ARIVI trigger is missing In StopCom mode, the bus guardian 
enters the FailSiient mode without generating an interrupt or setting error flags. This can be contrasted to the behavior 
in normal mode, where failure to receive the ARM signal would cause the generation of an error interrupt and error 

flags to be set. 

[0667] The following sequence allows the CC to make a smooth transition to the ShutdownRequest state. 

45 

• the HOST Initiates a transition from Normal mode to StopCom mode at the bus guardian 

• the StopCom command Is sent to the CC 

50 • at the end of the cycle the CC stops sending messages and stops sending the ARIVI trigger to the BG 

• the BG detects the missing ARM trigger and enters FailSiient mode 

• the CC switches off all internal clocks 

55 

Disabied (Listen oniy) 

[0668] The Disabled mode Is intended for node diagnosis. The bus guardian is powered and synchronized to the 
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CC. Bus access is disabled. Errors are stiii detected and error fiags are set. in case of errors the BG does not enter 
FaiiSiient mode, but instead remains in the Disabled mode. The Host may enable or disable Interrupt generation. 
Disabled mode may only be left by an SPI command from the Host. 

5 Bus guardian Scheduling Scheme 

[0669] Figure 61 shows an example of the media access pattern for a cluster operating In the mixed static/dynamic 
mode. The BG communication cycle start Is defined at the beginning of static slot 1 . Every static slot Is followed by an 
Inter-frame gap (IPG) of at least 2 macrotlcks [MT) In duration. The configuration shown In Figure 61 uses an Inter- 

10 frame gap of 3 MT. The BG stays open during the BG dynamic segment and closes 1 MT after the end of this segment. 
The communication cycle is completed by the Watchdog Disable Time (WDT) and the ARM Trigger Time (ATT). The 
start of the Watchdog Disable Time is aligned with the start of the Networi< idle Time, which is used by the cioci< 
synchronization algorithm in the CC to apply the clocl< offset correction. The Bus Guardian's supervision of the macrotici< 
period (MT watchdog) is disabled during this part of the schedule. This allows cioci< offset correction to shorten or 

15 lengthen macrotlcks by an amount that would exceed the configured limits of the macrotick supervision (see Section 
"BG-GG Synchronization"). The ARM Trigger Time Is needed to allow the Bus Guardian to process the ARM trigger, 
which synchronizes the BG schedule to the schedule of the CC. The ARM trigger Is expected to occur two macrotick 
periods in advance of the BG cycle start. During the ARM Trigger Time the CC shall not perform clock offset correction. 
[0670] Figure 62 shows the FlexRay media access pattern for a cluster operating In the pure static configuration. 

20 [0671] Configurations using the FlexRay pure dynamic or bytefllght compatibility modes are supported using the Bus 
Guardian Off mode. 

Key features of the bus guardian scheduling: 
25 [0672] 

• The scheduler at the BG Is clocked directly with the corrected MT signal (rising edge) from the communication 
controller 

30 * The BGEN signal, the signal that controls transmit access to thecommunicatlon medium, Is generated synchronous 
to the MT signal 

• The minimum Inter-Frame Gap duration is 2 macrotlcks 

35 I The Inter-Frame Gap may be extended by a safe pari (the duration of the safe part Is a configuration parameter) 

• Every BG static slot Is followed by an inter-Frame Gap 

• The communication cycle starts 2 macrotick periods after the ARM trigger (falling edge of the ARM signal) 

40 

• The ARM trigger time shall not be used for clock offset correction (this restriction applies to FPGA V5) 

• The bus guardian Is kept open during the BG dynamic segment 

45 » At the end of the BG dynamic segment the bus guardian stays open for the duration of one macrotick, which is 

equivalent to the tolerance part of an inter-frame gap 

• The Bus Guardian schedule contains a part (the Watchdog Disable Time, or WDT) during which the macrotick 
watchdog functionality is disabled. This part Is Intended for clock offset correction In the CC. 

50 

[0673] Figure 63 shows a scheduling example with an Inter-Frame Gap of 3 macrotlcks. With this scheduling scheme 
the bus guardian open windows do not overlap. This is achieved by adding a safe part to the Inter-Frame Gap pattern. 
During this safe part no transmission (by any node) Is allowed. The Bus Guardian Is able to detect media access errors 
during the safe part without any interaction with the CC. These errors might occur If a node Is operating slightly off 
55 specification with respect to the global time. 

[0674] Figure 64 provides a more detailed view of an Inter-Frame Gap of 3 macrotlcks in duration. The BG open 
window always starts one macrotick before the frame start and ends one macrotick after the frame end. With a sched- 
uling scheme based on the macrotick, these "tolerance" parts are needed to avoid cutting of frame data by the BG 
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open window. The IFG shown includes a safe part of one macrotick in duration. This safe part may be added in order 
to avoid overlapping BG open windows of adjacent static slots. The safe part is also required to support the detection 
of reception errors by the bus guardian. 

[0675] Table 27 summarizes the fixed and configurable parts of the bus guardian scheduling scheme. 
[0676] Version 5 Solution: The ranges of the configurable parameters shown in Table 27 are the ranges currently 
specified. The final ranges for these configurable parameters have not yet been determined and may be changed in 
future versions of the protocol specification. 

Table 27: 



Key Bus Guardian Schedule Parameters 


Name 


Length 


Remarks 


Fixed Length 


Tolerance part 


1 MT 


mandatory part of the interframe gap; also needed to close the 

BG after the end of the BG dynamic segment 


Arm Trigger Time 


2 MT 


no clocl< offset correction allowed 


Configurable Length 


Static slot length 


0 to 4095 IVIT 


CAS slot length assumed to be identical to static slot length 


BG dynamic segment 
length 


0 to 65535 MT 


BG is Icept open during BG dynamic segment 


Safe part 


Oto 15 MT 


optional part of the interframe gap; enables detection of reception 
errors at the BG 


Watchdog disable time 


up to 255 MT 


to be used for clock offset correction 



30 



Bus Guardian / Communication Controller Interface 
BG - CC Interface Signals 



[0677] Table 28 shows a list of bus guardian inputs and outputs at the interface between bus guardian and commu- 
nication controller. The transition of the ARM signal from HIGH to LOW is referred to as ARM trigger. 

Table 28: 



BG - CC Interface Signals 


Symbol 


DIR18 


ACTIVE 


Description 


MT 


1 




Corrected Macrotick - clock signal from CC 


BGT 


1 




Bus guardian tick - clock signal from CC 


ARM 


1 


LOW 


ARM trigger signal from CC 


BGEM 


0 


LOW 


BG Enable Monitor signal (inverted BGEN signal from BG scheduler).''^ 

Allows CC to monitor BG operation. 



' ° Data direction reiative to the Bus Guardian. 'I' represents an input to ttie BG, 'O' represents an output from the BG. 

Depending on the implementation a bus driver instead of the bus guardian may generate the BGEM signal. This would allow the CC to monitor 
BG operation directly at the medium access point. 

BG-CC Synchronization 



[0678] The FlexRay bus guardian approach maintains synchronization of the local BG schedule to the global time 
by basing all BG scheduling operations on a corrected macrotick signal provided by the CC. This allows the BG to 
perform its media access protection function (opening the transmit path one macrotick in advance of an active slot and 
closing it one macrotick after the end of an active slot) while being continuously synchronized to the global clock using 
the clock synchronization algorithm of the CC. Figure 65 shows the relation between theTXEN signal, which is activated 
by the CC in order to transmit data, and the BGEN signal, that enables the transmit path at the BG. Both signals are 
derived from the MT signal available to both the CC and the BG. 
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[0679] Figure 65 also shows that the effect of the propagation deiays t-|, X2 arid in relation to the minimum MT 
period 7_MTco;.^must be considered, in order to open the transmit path before the transmission starts. (V5: The detaiied 
timing depends on implementation restrictions and will be specified in a separate document.) 
[068Q] An second clock signal, bus guardian tick (BGT), is used for supervising the period of the MT signal provided 

5 by the CC. The Communication Controller shall generate the BGT signal such that its period is independent from the 
clock correction performed by the CC. For example, the BGT signal could be derived from the application of a pro- 
grammable prescaler to the oscillator Input of the Communication Controller. The Bus Guardian uses the BGT signal 
to perform a supervision of the duration of the corrected macrotick by checking if the MT / BGT ratio deviates from the 
nominal ratio by more than a pre-defined configurable limit. Acceptable deviations from the nominal limit may be caused 

10 by the clock rate correction algorithm as it increases or decreases the length of certain macroticks to maintain the 
overall clock rate. 

[0681] Clock offset correction is applied during the network idle time and may require the application of large cor- 
rection terms that would result in macroticks that are shortened or lengthened such that they would exceed the con- 
figured limits forthe macrotick period supervision at the BG. In order to allow the application of such large clock offset 
15 correction terms, the macrotick period supervision is disabled during the part of the schedule where these offsets are 
corrected. The period the macrotick supervision is disabled, referred to as the Watchdog Disable Time (WDT), is aligned 
with the Network Idle Time at the CC. 

Expected ARM Timing 

20 

[0682] Before the initial ARM triggerthe MTsignal is ignored to allow large initial offset corrections without BG-related 
restrictions to the MT period. After the initial ARM trigger the BG scheduler is directly clocked with the MT signal and 
the ARM trigger is used to indicate the start of the communication cycle. The bus guardian expects the regular occur- 
rence of the ARM trigger and check for this at the end of each cycle. 
25 [0683] Figure 66 shows the expected ARM timing of a cold start node. When receiving the initial ARM trigger, the 
BG initializes the schedule and opens for the Collision Avoidance Symbol (CAS) slot. After transmitting the CAS, the 
CC sends a second ARM trigger. The BG detects this second ARM trigger, reinitializes the BG schedule, and starts 
controlling bus access according to the schedule. 

[0684] Figure 67 shows the expected ARM timing of an integrating node, which starts with the regular schedule and 
30 does not transmit a Collision Avoidance Symbol. When receivingthe initial ARM trigger, the BG initializes the schedule. 
At this point the BG can not determine whether a node Is a cold start node or an Integrating node and thus has to open 
for the CAS slot. As a result, the bus guardian of an integrating node does not protect the first static slot of the first 
communication cycle, If the node is an integrating node the CC starts with the regular schedule and the next ARM 
trigger does not occur until the end of the cycle. Specifically, an integrating node does not send a second ARM at the 
35 end of the first static slot. (A cold start node would provide an ARM trigger after transmission of the Collision Avoidance 
signal.) The bus guardian detects the "missing" second ARM trigger and continues to work according to the regular 
schedule. 

BG - CC Interface Requirements Summary 

40 

[0685] 

• The Initial offset correction (up to 3000 ppm) must be completed before the initial ARM trigger occurs. Before this 
initial ARM trigger the BG ignores the MT signal. 

45 

• After detection of the initial ARM trigger the following requirements are valid: 

• Expected minimum regular MT period: Ti^-j-f^^^) >^^ls 

50 • Expected minimum corrected MT period: Ti^f„i„) > 0.5 |is 

• Expected minimum MT pulse width (low or high): 250 ns 

• The CC provides an MT signal, that is used as the clock for the BG scheduler 

55 

• The MT signal that the CC provides to the BG shall be the same internal corrected macrotick signal that the CC 
uses to schedule its internal activities. This implies that the CC must do more than provide a MT signal that is at 
the correct frequency; it must match CC's internal view of a corrected macrotick. 
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The ARM signal from the CC is generated synchronous to the MT (falling edge of the ARiVI signal is aligned to the 

rising edge of the MT signal) 

The communication cycle is preceded by a period two macroticl<s in duration (the ARIVI trigger time), which the 
CC shall not use for clock offset correction. Clock rate correction may be performed during ARM Trigger Time (ATT). 

Expected minimum ARM active duration: T/,BMfm/n;= 2 MT 

Expected maximum ARM active duration: tbd (shall be shorter than CAS slot) 

Expected minimum BGT period: Tg^j^^j^^ > 250 ns 

Expected BGT duty cycle: 50% (tolerance tbd) 

The BG communication cycle starts at the beginning of the first static slot 
The number of macroticks per cycle is not variable 
BG Schedule Reset 

20 

[0686] FlexRay nodes that enter communication via the coldstart path have a requirement to be able to reset the BG 
schedule if they need to re-enter listen static state. The BG is able to detect this situation by monitoring the ARM signal. 
The bus guardian continuously monitors the ARM signal and detects if the ARM trigger at the cycle start is missing. 
The communication controller causes a bus guardian schedule reset by not sending the regular ARM trigger to the 
25 bus guardian. 

[0687] Bus guardian schedule resets are allowed only during startup of a coid start node. For this purpose the BG 
needs to distinguish between nodes in cold start state and integrating nodes. Coldstart nodes are identified by detection 
of a second ARM trigger at the end of the first static slot (see Section 0); this pair of ARM trigger events is called 'double 
ARM trigger'. 

30 [0688] BG schedule reset requests need to be handled at the bus guardian in a way that is closely related to the 
protocol specification. So, any change of the FlexRay startup procedure may Influence the required BG schedule reset 
procedure, described in the pseudo-code below. 

35 

Cold Start Count = 0; 
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init: // BG normal mode; 

waiting for initial ARM 

if double ARM trigger detected // CC cold 

start state 

BG_reset = enabled; 

Cold_Start_Count ++; 

while (Cold_Start_Count < pColdStartMax) 
wait for start of next cycle; 
if double ARM trigger detected 
condition 

AE^M error CBG enters fail-silent mode) 
elseif single ARM trigger detected 
in cold start state 

Cold_Start_Couat ++; 
else // missing ARM trigger 

EG schedule reset - goto init // CC re- 

entered listen static state 
end; 
end; 
end; 

BG reset == disabled; // integrating node 

// or cold start concluded 



// error 

// CC stays 



30 



while (1) 
mode 

if no ARM at cycle start detected 
ARM error; 
permanently disabled 

end; 
end; 



Bus Guardian Configuration Parameters 



// BG normal operation 
// BG schedule reset 



[0689] A subset of the bus guardian configuration parameters, related to the bus guardian scheduling scheme is 
shown in Tabie 29. 



Table 29: 



Bus Guardian Configuration Parameters (Subset) 


Name 


Description 


Range / Value 


Unit 


qdBGSIot 


static siot iength 20 21 


0 .. 4095 


MT 


gdBGDynSegment 


BG dynamic segment iength^s 


0 .. 65535 


MT 


qdBGSafePart 


Inter-frame gap safe 


0 .. 15 


MT 




part 






gdSGNatchdogDisable 


watchdog disable time iength^s 


0 ,. 255 


MT 










pActiveStaticSlotI 


open static slot number 1^4 


0, 1 .. 102325 




pActiveStaticSlot2 


open static slot number 2 


0,1.. 1023 





Does not include the inter-frame gap {gdBGSafePart + 2 MT) 
2"' By definition CAS siot iength is identical to static slot length 

22 Does not include the tolerance part (a constant 1 MT) - see Figure 61 

23 Does not include the ARM trigger time (a constant 2 MT) 
2'^ Open static slots must be configured in ascending order 

Unused entries are identrfied by slot number = 0 
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Table 29: (continued) 



Bus Guardian Configuration Parameters (Subset) 


Name 


Description 


Range/ Value 


Unit 










pActiveStaticSlotie 


open static slot number 1 6 


0, 1 .. 1023 




gNumberOfStaticSlots 


last static slot number 


2 .. 1023 





10 
15 
20 
25 
30 
35 
40 
45 
50 
55 
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Appendix B 
Frame Checks 

Frame Checks 
Introduction 

When a frame is received a set of checks must be performed to 
determine if the data in the frame, or information about the 
reception of the frame (arrival time, cycle counter, etc.) 
should be accepted into the Communications Controller. For 
example, before frame data is passed up to the host through 
the CHI the Communications Controller performs a check of the 
Frame CRC. As another example, before a frame's reception time 
is used for the clock synchronization algorithm the CC 
performs a check to determine if the frame has the Sync Bit 
field set. 

At a conceptual level, a FlexRay Communications Controller has 
several logical blocks that act as consumers of frame data (or 
information about the reception of the frame) . Examples of 
these logical blocks include the clock synchronization 
mechanism, the startup mechanism, the error management 
mechanism, the host interface, etc. Each of these logical 
blocks may have different requirements for the criteria that 
determine whether a frame is "accepted" for the purposes of 
that block. For example, the clock synchronization mechanism 
may require that a frame has the Sync Bit set in order to 
accept the frame, but the host interface has no such 
requirement. Also, it is possible that within a single logical 
block the state of the Communication Controller may affect 
that block's criteria for "accepting" a frame. For example, 
the startup mechanism may check that a frame' s cycle counter 
matches the CC s current view of cycle count after the system 
has been synchronized, but may ignore this check prior to 
synchronization. 
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The individual logical blocks need to specify the acceptance 
criteria that determine whether they will accept a particular 
frame. These criteria may be thought of being constructed out 
of a set of "fundamental" tests that are applicable to one or 
more criteria. For example, the concept of checking for a 
valid CRC is likely to apply to .tany criteria. This section 
defines these "fundamental" tests that are referenced in other 
sections of the specification. 

Notation 

The result of the check is represented by a variable of the 
form vCheckName, where CheckName is the name of the particular 
check. A value of "T" indicates that the respective check was 
successful for that frame. The concept of "successful" or 
"unsuccessful" checks is actually somewhat ambiguous. In 
general, a check is considered "successful" if it would tend 
to result in the acceptance of a frame. The formal definitions 
of the individual checks, and the inclusion of those checks in 
acceptance criteria, resolve any ambiguities. A value of "F" 
indicates that the check was unsuccessful. 

Several of the checks or variables defined in this section are 
individually applicable to the frames received on both 
channels of a multiple channel system. In this case, there are 
actually two checks or variables, one for Channel A and the 
other for Channel B. When this is the case, the check or 
variable is given a name of the form CheckName_x. A check of 
this form shall be interpreted as applying to the channel in 
question (i.e., the channel on which the frame was received). 
Where it is necessary to be explicit as to which channel is 
actually being referenced, the suffix _x will be replaced with 
a suffix indicating the appropriate channel (_A or _B) . 

Frame consistency cheeks 

Frame Coding Cheeks 
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The check CheckFEameCoding_x suitimarizes the results of coding 
checks performed against a set of coding-dependent coding 
rules that are applied upon frame reception. 

For NRZ 8N1 coding the following applies: 

if (vCheckFSS_x == "T" MD vCheckByteDelimiterBits_x == "T") 



// " 

vCheckFrameCoding_x = "T"; // 
else // 

vCheckFrameCoding_}i = "F"; // 
end; // 



Comment: This section will be expanded as other coding methods 
are defined. 

Frame CRC Cheeks 

The check CheckCRC_x checks the consistency of a frame and 
it's CRC. This test is performed according to the procedure 
described in the chapter 'Trame and Symbol Formats". The 
variable vCheckCRC_x denotes the result of the check for the 
respective communication channel: 



if CRC_x ( fFranie_x) == gCRCseed^x // 
vCheckCRC_x = "T"; // 

else // 

vCheckCRC_x = // 

end; // 



In the pseudocode above the variable fFzame_x represents the 
entire frame received on the channel, including the frame CRC. 

Note that CRC_x ( ) implies that the CRC check appropriate for 
the frame and channel are applied - for example, byteflight 
frames use a different CRC mechanism than FlexRay frames. 
Also, for FlexRay frames the CRC mechanism for channel A is 
different than the CRC mechanism for channel B. Similarly, the 
variable gCRCseed_x represents the appropriate value for the 
CRC generator that is being used (byteflight or FlexRay) . 
Although FlexRay frames use different initialization values 
for the CRC generators on channels A and B, the CRC seed value 
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used in this check is identical, bytefilght frames use a 
different seed value. 

Header CRC Checks 

The check CheckHeaderCRC_x checks the consistency of the 
header and the header CRC. This test is performed according to 
the procedure described in the chapter ''Frame and Symbol 
Formats". The variable vCheckHeaderCRC_x denotes the result of 
the check for the respective communication channel: 

if CRC if PayloadLength_x, fSyncBit_x, fHeaderCRC_x) == 



gHeaderCRCseed II ~ 

vCheckHeaderCRCjK = "T"; // 
else // 

vCheckHeaderCRC_x " "F"; // 
end; // 



In the pseudocode above the CRC function is the generator for 
the header CRC. The arguments shown are concatenated in the 
order indicated to form the input to the generator. 

Frane content checks 

Syne Bit Checks 

The check CheckSyncBitS6t_x checks whether the sync bit is set 

within the received frame. The variable vCheckSyncBitSet_K 
denotes the result of the check for the respective 
communication channel. 



if fSyncBit_x == 1 // 
vCheckSyncBltSet_x = "T"; // 

else // 

vC/iecJcSyncBitSet x = "F"; // 

end; ~ // 



The check CheckSyncBitMatch checks whether the sync bits 
received on the respective communication channels within one 
communication slot have identical values. The variable 
vCheckSyncBitMatcb denotes the result of the check. 
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if fSyncBit_A == fSyncBit_B // 
vCheckSyncBitMatch = "T"; // 

else // 

VCheckSyncBitMatch = "F"; // 

end; // 

Frame ID Checks 

The check CheckFraroelDMatch checks whether the frame IDs 
received on the respective communication channels within one 
communication are identical. The variable vCheckFramelDMatch 
denotes the result of the check. 



if fFrameID_A — fFramelD^B // 
VCheckFramelDMatch « "T"; // 

else // 

VCheckFramelDMatch = "F"; // 

end; 



The check CheckFrameID_x checks whether the frame ID 
fFrameID_x matches the current view of the slot ID 
vCurrentSJotlO within the communication controller. The 
variable vCheckFrameID_x denotes the result of the check for 
the respective communication channel. 



if f"FrajneID_x == vCurrentSlotID // 
vCheckFrameID_x = "T"; // 

else // 

vChecArFramelD x = "'F"; // 

end; ~ // 



The check CheckFrameIDStaticRange_x checks whether the frame 
ID fFrameID_x is within the configured range of acceptable 
static segment slot ID's. The variable 

vCheckFramelDStaticRange _x denotes the result of the check 
for the respective communication channel. 

if ( (fFrafneID_x >= 1) AND // 

lfFrameID_x <= gNumberOfStaticSlots )) // 
vCheckFramelDStaticRange_x = "T"; // 

else ~ // 
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vCbeckFrameIDStaticRange_x = "F"; // 
end; // 



The check CheckFrameIDDynamicRange_x checks whether the frame 
ID fFrameID__x is within the configured range of acceptable 

dynamic segment slot ID's. The variable 

vCheckFrameIDDynamicRangB_x denotes the result of the check 
for the respective communication channel. 



if l{fFrameID_x > gNumherOfStaticSlots ) AND // 
{fFt:ameID_x <= gSlotlDMax) ) II 
vCheckFcameIDDynamicRange_x = "T"; // 

else // 

vCheckFrameIDDynamicRange_x = "F"; // 

end; // 

Static Frame Payload Length Checks 

The check CheckStaticPayloadLength_x checks whether the number 
of bytes claimed to be contained within the payload' segment 
(via the fPayloadLength field) of the frame matches the number 
of payload segment bytes configured within the communication 
controller in the variable gPayloadLengthStatic. The variable 
vChecJrStaticPay2oadLength_x denotes the result of the check 
for the respective communication channel. 



if fPayloadLength_x == g-PayloadiengthStatic // 
vCheckStaticPayloadLength_x = "T"; // 

else // 

vCheckStaticPayloadLength_x - "F"; // 

end; // 

Payload Length Range Checks 

The check CheckReceivedPayloadLength_x checks whether the 
value in the fPayloadl^ngth field of a frame is consistent 
with the number of payload segment bytes actually received by 
the communication controller. The variable 

'vCheckRec&ivBdPayloadliength_x denotes the result of the check 
for the respective" communication channel. 
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if (<2 * fPayloadLength_x ] == vPayloadByte3Received_x) // 
vCheckReceivedPayloadLength_K = "T"; // 

else // 

vCheckReceivBdPayloadLength_x = "F"; // 

end; // 

In the pseudocode above, the variable vPayloadBytesReceived_x 
represents the number of bytes actually received in the 
payload segment of the frame received on channel x. 

Version S Solution: FPGA V5 does not actually do an explicit 
payload length check. This check is implicit in the frame 
reception mechanism, however - a short frame would generate a 
NRZ 8N1 coding error, and a long frame would fail the idle 
check at the end of the frame. 

Cycle Counter Checks 

The check CheckCycleCountMatch checks whether the cycle count 
values received on the respective communication channels 
within one communication slot are identical. The variable 
vCheckCycleCountMatch denotes the result of the check. 



if fCycleCount_A == fCycleCount_B // 
VCheckCycleCountMatch = "T"; // 

else // 

vChecJtCycieCountAfatch " "F"; // 

end; // 



The check CheckCycleCount_x checks whether the received cycle 
count value fCycleCount_x matches the communication 
controller's current view of the cycle count contained in the 
variable vCycle. The variable vChec^CycIeCount__x denotes the 
result of the check for the respective communication channel. 



if /CycIeCount_x == vCycle II 

vCheckCycleCount_x = "T"; // 

else // 

vCheckCycleCount_x = "F"; // 
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end; // 

The check CheckCycleCounterEven_x checks whether the received 
cycle count value fCycleCaunt_x is even. The variable 
vCheckCycleCounterEven_x denotes the result of the check for 
the respective communication channel. 



if {fCycleCount_x mod 2) == 0 // 
vCheckCycleCountEven_K = "T" // 

else // 

vCheckCycleCountEven_x = "F"; // 

end; // 



MullFrameCheeks 

The check CheckNullFrame_x checks whether the received frame 

was a null frame, i.e., a frame with the Data Update Bit field 
set to zero. The variable vCheckNuliFrame_x denotes the result 
of the check for the respective communication channel. 

if fDataUpdateBit_x == 1 // 
vCheckNullFzame_x = "T"; // 

else // 

vCheckNullFrame_x = "F"; // 

end; // 



Frame Timing Checks 

The check CheckT_RWl_x checks whether the time reference point 
of the frame on channel x was received within the receive 
window pdT_Rtil. The variable vCheckT_RWl_x denotes the result 
of the check for the respective communication channel, 

if { { {vtExpectedTRP - pdT_RNl) < vtTimeReferencePoint_}< ) 
AND // 

(vtTimeReferencePaint x <= {vtExpectedTRP +pdT Rffl))] 
// ~ 

vCheckT_RWl_x = "T"; // 
else // 

vCheckT RWl x = "F"; // 
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end; // 

In the pseudocode above, the variable vtExpectedTRP represents 
the expected time of reception of the frame's time reference 
point. A single parameter is used to express the expected 
arrival time on both channels. This assumes that the expected 
time reference point of frames on both channels is identical, 
implying that any channel-specific delay time corrections are 
applied to the received reference point times prior to any 
testing. The variable vtrijnei?e/ereiicePoint_x represents the 
actual arrival time of the reference point of the frame on 
channel x, as measured by the local clock. 

Channel Idle Detection 

The mechanism for the detection of channel idle depends on the 
characteristics of the physical layer. In particular, the idle 
detection method is different for 2-State physical layers 
(which have states of and ^0') than it is for 3-State 
physical layers (which have states of '0', '1', and "medium 
idle") . 

The following sections define the idle detection mechanisms 
for these different types of physical layers. 

Channel Idle Detection for 3-State Physical Layer 

3-State physical layers have a specific state for "medium 
idle". Channel idle shall be detected if the "medium idle" 
state is signaled continuously for at least 1 * grdBit. This 
idle detection mechanism is independent of the coding method. 
This is in contrast to idle detection for the 2-State physical 
layer which is coding method-dependent. Figure 68 shows the 
specifics of the 3-State idle detection mechanism. 

Channel Idle Detection for 2'State Physical Layer 
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Comment: Channel idle detection for 2-State physical layers is 
coding method-dependent. Currently the only defined coding 
method is NRZ 8N1. As additional coding methods are added to 
the protocol addition coding specific sections will be added 
to this section. 

2-State physical layers do not have a state that signals that 
the medium is idle, and thus must base their idle detection 
mechanisms on the data levels available on the medium. The 
particular idle detection mechanisms are coding meuhod- 
dependent, and are defined in the following sections. 

2 -State Physical Layer with NRZ 8N1 Coding 

For 2-State physical layers using the NRZ 8N1 coding method, 
channel idle shall be detected if the '1' state is signaled 
continuously for at least 11 * gdBit. Figure 69 shows the 
specifics of the 2-State NRZ 8N1 idle detection mechanism. 

Comment: Is a coding method other than NRZ 8N1 possible? How is 

bus idle detection performed in the case of a 2-State physical 

layer and a new coding method?. It is likely that the NRZ 8N1 

idle detection mechanism would work in all cases. Depending on 

the coding method a shorter check may be possible, however. 

Channel Idle Checks 

The check CheckidleBeforeReception_x checks if the channel 
idle detection state machine is in the channel idle state 
before a transition into the frame reception state occurs. 

The check CheckldleAf terReception_x checks if the channel idle 
detection state machine is in the channel idle state after the 
expected end of a frame. The expected end of frame is derived 
from the payload length field of the frame. 
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Example: When using NRZ8N1 coding the expected end of frame is 
the last stop bit of the Last CRC byte. 

Symbol checks 

The check CheckMormalSynibol_x checks if an SOC Normal symbol 
is received on the respective channel. This check is only 
applicable for systems in the FlexRay pure dynamic or 
bytef light compatibility mode. The check passes if 

• the check CheckldieBef oreReception_x passes, 
and 

• a continuous sequence of logic '0' samples 
with a duration between 28.5 * gdBit - 31.5 * 
gdBit are received. 

The check CheckAlarraSy!Tibol_x checks if an SOC Alarm symbol is 
received on the respective channel. This check is only 
applicable for systems in the FlexRay pure dynamic or 
bytef light compatibility mode. The check passes if 

• the check CheckldieBef oreReception_x passes, 
and 

• a continuous sequence of logic '0' samples 
with a duration between 18.5 * gdBit - 21.5 * 
gdBit are received. 
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The check CheckCollisLonAvoidanceSynibol_x checks if a 
collision avoidance symbol is received on the respective 
channel. This check is only applicable for systems in the 
FlexRay pure static or mixed static/dynamic mode. The check 
passes if 

• the check CheckldleBef oreReception_x passes, 
and 

• a continuous sequence of logic '0' samples 
with a duration between 28.5 * gdBit - 31.5 * 
gdBit are received. 

Chapter I 

FlexRay Acknowledgement Service (FAS) 

General 

[0690] 

• Acknowledgment is not required for V5. 

• Acknowledgement must be discussed together with a functional network management and other diagnosis services 
like link diagnosis. 

Potential 

[0691] The FiexRay acknowledgement service is an optional and configurable service that could be used for the 
following functions 

• Link diagnosis (outgoing, incoming, local, remote) 

• Communication channel and star diagnosis 

• Frame transmission acknowledgement 

• Support of data consistency protocols which have to be established on application level 

• Functional network management services 
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30 



General Description 
[0692] 

• The acknowledgement service is a diagnosis service for tlie communication subsystem. It can be exploited by the 
application according to the safety requirements of the overall application system. It is designed to provide basic 
data transmission status Information throughout the distributed communication subsystem. 

The acl^nowledgement service is based on individual data frames, not on nodes. 

The basic diagnosis procedure Is the status information of the correct reception of an a-priorl known frame identifier 
in combination with the acknowledgement of the application. This can be configured. 

The acknowledgment service does not evaluate the content of the frame itself. This has to be done in the application 

and given to the acknowledgement protocol service. 

It is assumed that every frame identifier is transmitted periodically. 

The application can lookup status Information on whether sent frames have been received by other communication 
controllers correctly, i.e. the sender's view. The receiver's view provides status information on whether received 
frames have also been received correctly by other communication controllers. 

The acknowledgement service is an optional and configurable protocol service. 

Several groups of related frames can be established. 

The acknowledgment status information can be overruled by the application (Invalidated or validated). 

The acknowledgment service Is Individually executed for each channel. It Is therefore possible to retrieve status 
information on every individual frame on every individual channel. 

The service can be applied for frames in the dynamic part. Therefore it can be checked whether specific dynamic 
frames have been sent within a round. 



Frame Format 
Header 

[0693] Two bits indicate the length of the acknowledgement vector which will be transmitted in the frame body (see 
Frame Fomnat in Section xxx): 

Table 30: 



Acknowledgment Header Field 


AckBIt 


AckBIt 


AckVector 


Remark 


A1 


AO 


length 




0 


0 


Obit 


No acknowledgement configured 


0 


1 


8 bit 




1 


0 


16 bit 




1 


1 


24 bit 





[0694] Open Topic: The header infonnation for acknowledgement can be reduced to a single bit indicating the pres- 
ence of an configured acknowledgement vector within the frames. 
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Frame Body 

[0695] According the two bits in tlie frame lieader 0...3 bytes of tfie acknowledgement vector ( or according tfie 
configuration and tiie single indicating bit in the header. 

Table 31 : 



15 



Frame Formats 


Header 


Frame Body 


A1 


AO 


Byte 


0 


1 


2 


3 


4 


5 


6 




0 


0 




Msgid 


Msgid 


Data 0 


Data 1 


Data 2 


Data 3 


Data 4 




0 


1 




Msgid 


iVIsgid 


Acl< Byte 1 


Data 0 


Data 1 


Data 2 


Data 3 




1 


0 




Msgid 


iVIsgid 


Acl< Byte 1 


Acic Byte 2 


Data Data 0 1 2 


Data 




1 


1 




IVIsgId 


IVIsgId 


Acl< Byte 1 


Ack. Byte 2 


Ack Byte 3 


Data 0 


Data 1 





Algorithm 



20 Conventions 

[0696] On every node a set of iD's of reiated frame identifiers can be configured which iscailed an acl<nowledgement 
group. Severai groups can be established depending on the implementation. Each ID should be assigned to only one 
group in order to get a consistent acknowledgement matrix. 
25 [0697] Every acknowledgment group is defined by an acknowledgment group vector. The acknowledgment group 
vector is an ordered list of frame identifiers. Every entry of the acknowledgement group vector is set of {ID, Channels, 
Direction}. ID specifies the frame identifier, Channels specifies one or more channels on which the ID Is broadcast, 
Direction specifies if the ID is either sent (TX) or received (RX). 

[0698] Every communication controller collects status infonnatlon on the correct reception of group members In a 
30 so-called local status vector (LocStatVec). 

[0699] The application status vector (ApplStatVec) is controlled by the application. Each bit of this vector reflects the 
application view of a specific ID. 

[0700] The acknowledgement status vector (AckStatVec) is derived from the LocStatVec and the ApplStatVec. 

[0701] Every communication controller holds a local acknowledgment matrix (AcknMat) for every group. Line i of the 
35 acknowledgment matrix holds the last acknowledgment status vector of frame IDi, i.e. its local view of frame status 
before sending. Therefore it is called the external status vector (ExtStatVec). Column j represents the (collected) global 
status vector (GlobalStatVec) on frame IDj over ail group members. 

Fehler! Kelne gUltlge Verlcndpfung. 

40 

Tabie 32: Acknowledgement matrix of an acknowledgement group 
Basic Principle 

45 [0702] The communication controller checks the correctness of incoming frames and marks the specific ID flag in 

the LocStatVec. 

[0703] Before sending the local status vector along with a specific frame, the local status vector can be combined 
with the application status vector (ApplStatVec). The combination procedure can be defined to be AND, OR, or PURE. 
The AND combination with the ApplStatVec acknowledges only frames which are proved correctly by the communl- 
50 cation controller and the application. The OR combination with the ApplStatVec acknowledges either frames proved 
correctly by the communication controller or the application, I.e. the application can overrule the local view of the 
protocol. The PURE combination completely fades out the local view of the protocol. 
[0704] The ExtStatVec is cleared at the beginning of each cycle. 

[0705] The resulting global status vector for every frame is stored in the last global status vector at the end of the 
55 cycle to present consistent status information to the application. (Please note that the acknowledgment matrix is per- 
manently updated during the communication cycle). 

[0706] Open Topic: Since the acknowledgement matrix is updated during every cycle a shadow buffer concept must 
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be established in order a transmit a consisting view. 

Extensions 

5 Static and Dynamic Communication 

[0707] Static and dynamic frames can be Inciuded In the acl<nowiedgment scheme. It has to be guaranteed, that 
dynamic frames are sent once In a communication cycie. For dynamic frames the controiier has to detect, If a certain 
frame is not sent in the dynamic part, i.e. its min-siot is empty. 

10 

{multiplexed Communication 

[0708] The Acknowledgement Diagnosis Service for muitlpiexed communication in the sense that one slot Is multi- 
plexed between severai nodes is not supported. 

15 

R/luiti-Cliannei Communication 

[0709] The aclcnowiedgment group vector hoids Infonnation on the respective communication channei. it is therefore 
possibie to retrieve status information on every individual frame on every individual channel. 

20 

integrity Level Counters 

[071 0] Every globai status vector can be combined with an aipha-counter, the so-caiied integrity ievei counter. To be 

defined later. 

25 

Agreement Service 

[0711] There is no agreement mechanism to provide a consistent view of the giobai status vector within fault-free 
nodes. Nevertheiess, the global status vector provides a duster wide snapshot of the indivlduai views of aii commu- 
te nication partners, if the locai view of a specific frame differs from the giobai view, the appiication decides If it uses its 
content. 

[0712] It is the philosophy of the FlexRay acknowledgement service to provide sufficient status Information, but to 
refrain from Implementing higher-level agreement and consistency protocols. The requirements for such mechanisms 
are highly application dependent and should therefore not be implemented in the communication protocol. 

35 

Chapter J 

Operation iVIodes and HW States (not V5) 
40 FlexRay Node 
Concept 

Hardware Modules and their Operation Modes 

45 

Assumption 

[0713] A FlexRay node consists of several modules 
50 • CC and host (and the software) 

• one BD at least 

• one voltage regulator at least 

55 

• optional one or two BG 

[0714] Each of this module supports several operation-modes (states) which cause the operation modes (states) of 
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the node. 

[0715] Figure 70 shows a block chart of a FlexRay node and operating modes (states) of each module. Each of the 
modules is integrated into a main control loop. Starting from the ECUs sleep-mode we can find: 
[0716] Wake-up: 

5 

• stable state (sleep-mode of the ECU) 

• the voltage regulator Is off 
10 * the host Is not powered 

• the BD monitors the bus to detect the wake-up sequence 

• if the wake-up sequence is recognised by the BD or a local wake-up signal Is set, the BD activates the voltage 

15 regulator by a suitable control signal (e. g. INH) 

• the host is powered by the voltage regulator 

• the host does his job 

20 



Sleep: 
25 [0717] 

• the sleep request Is acknowledged by a NM protocol running on the host 

• each host Initiates synchronous the shutdown of the communication system or communication subgroup (selective 
30 sleep) by de-activatIng the CC and BG by a suitable control signal (e.g. SPI - StopCom) 

• the host de-activates the BD by a suitable control signal (e. g. SLPN or SPI) 

• the BD de-activates the voltage regulator and monitors the bus 

35 

• stable state (sleep-mode of the ECU) 

• see 1st dot 

40 [0718] Figure 71 shows operating modes of a FlexRay ECU regarding HW and HW controlling. 
Operating Modes of the Application and their Controlling 

[0719] Proposal each ECU supports 3 operating modes (states): 

45 

• Normal 

• one bus is active at least 

• distributed application active 

50 

• StandBy 

• each bus Is Inactive 

• local application active or in-active 

55 * one voltage regulator Is active Inside an ECU at least 

• Sleep 
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• the application is inactive 

• the host is not powered 

• the ECU is powered 

5 Operating Modes of the Application and the corresponding l-IW 

[0720] This chapter describes the ECU as a state transition chart combining host, voitage regulator(s) and the bus 
driver(s). 

10 Assumptions 

[0721] 

• the NM manages the operation modes of the node and the net supported by net-wide negations 

15 

• a wake-up from the bus has to be conflnned 

• to be protected against e. g. electromagnetic interference 
20 • by the GG-driver-servlce "PasslveStartUp" 

• a sleep command has to be confirmed 

• to be protected against unstable states of the net 

25 

• by a NiVI-service "GotolVlode(Sieep)" 

• the source of a wake-up event has to be detected 

30 * to be able to start suitable confirmation procedures 

[0722] Figure 72 shows operating modes (states) Inside a FlexRay node, whereby dotted arrows state transitions 
specific to the application. 

[0723] A typical operation cycle from the ECU will work In the following way: 

35 

• stable state (sleep-mode of the ECU) 

• the voltage regulator Is off 
40 * the host Is not powered 

• the ECU Is powered 

• the BD monitors the bus to detect any wake-up sequence 

45 

• if the BD detects any wake-up sequence 

• the BD switches to normal mode 

50 • the BD switches the voltage regulator to VccOn 

• the host (and the CC) will be powered 

• after finishing the reset procedure the host detects the wake-up source 

55 

• a detected wake-up from the bus activates the WakeUpConflnnatlon Mode hidden In the NM 

• the bus wake-up could be caused by any electromagnetic Interference 
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• the host-NM makes the CC to start-up the net passively ("PassiveStartUp") 

• just valid communication on the bus make the CC to participate in the start-up 
5 • if the CC is able to start-up the net, the host can do his distributed job 

• 

• to finish the distributed job, the host has to waitfor a net-wide negotiation (in case of selective sleep: sub-net-wide 
10 negotiation) result activated by a NIVI-service "Gotol\^ode(Sleep)" 

• as soon as the net confirms this sleep-request, the CC has to stop the communication ("StopCom") and the BD 
has to pass the bus to the low-power state ("BD_Standby") 

15 • hidden inside the NM 

• Hint: the state transition from Normal to Standby can be aborted e. g. when receiving an urgent application request 

• If having finished the net-communication the host can do his local job 

20 

• to re-activate the distributed job, the host has to make the CC to start-up the net actively ("ActiveStartUp") 

25 • valid communication can be detected by all the other nodes 

• they can participate in the distributed start-up 

• to finish the local job, the host has to 

30 . switch the BD to its sleep mode ("BD_Sleep") 

• wait for the power de-activation 

• Hint: the state transition from Standby to Sleep can be aborted e. g. when receiving an urgent application request 

35 

• stable state 

• see 1st dot 
40 FlexRay Active Star 

Expected Behavior 

without a CC and without a host 

45 

[0724] 

• • active if 

50 » a message pattern was received 

• • fail silent 

• e.g. in case of a permanent bus busy on one branch 

55 

• • passive if 

• no message pattern was received during a predefined time-out 
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with a CC and with a host 
[0725] 

5 • . according a FlexRay node 
Bus-Wake-Up 
Concept 

10 

Wake-up via the bus 

[0726] The FlexRay CC supports a dedicated wake-up sequence. The wal<6-up sequence is sent out once before 
the startup of the protocoi for a defined duration. The sending of the wai<e-up sequence is initiated by the host and 
15 generated by the CC. The wal<e-up sequence is detected by the BD. Different wai<e-up sequences for optical and 
eiectricai physical layers due to robustness of the wake-up detection in the BD are supported. 
[0727] The CC can be configured lor active wake-up (Initiate wake-up) and passive wake-up (only wake-up if initiated 
by other nodes). 

[0728] The unintended sending of the wake-up sequence during normal operation must be prohibited. 

20 

Selective Bus Wake-Up Filter 
[0729] not required 
25 Bus Wake-Up Filter Inside the BD 
[0730] TBD 

Bus Wake-Up Filter outside the BD 

30 

[0731] The BD will not be able to prevent a node being waked-up by any kind of noise. In this case the node will be 
powered and the software will start-up. 

[0732] To ensure the operation robustness just valid communication should be able to start-up the networked system. 
Requirement: A node has to confirm a bus-wake-up request. 
35 Requirement: A node may start-up the networked communication actively after having confirmed the bus-wake- 

up request. 

Definition: "confirmed bus-wake-up request": valid message 
Bus Wake-Up Filter Inside the CC 

40 

[0733] The CC has to support the confirmed wake-up. 

Requirement: the CC has to support 2 start-up procedures: 

1 . active start-up 
45 2. passive start-up 

Requirement: The active start-up procedure may Initialize the start-up of the network by sending dedicated 

messages. 

Requirement: The passive start-up procedure may not Initialize the start-up of the network. 
50 Requirement: The passive start-up procedure may participate actively In the start-up when receiving start-up 

messages. 

Requirement: The passive start-up has to be aborted If no start-up message was received during a time-out 
Explanation: If a transient Interference wakes up the BD, each node will activate the passive start-up procedure. 
No valid message can be received by any node. Each passive start-up will be aborted after the time-out. 
55 Explanation: If at least one node activates the active start-up the start-up of the networked system will run perfect. 
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Bus Wake-Up Filter inside the Host 

[0734] The host has to prevent the networked system from being activated by wake-up interference passed tfie BD. 
Requirement: the host has to detect two states: 

5 

1 . the host received a confirmed wake-up event - it has to seiect the active start-up procedure of the CC 

2. the host received a non-confirmed wake-up event - It has to select the passive start-up procedure of the CC 

Opticai wal<e-up scheme (bytefilght compatible) 

10 

[0735] In order to support the wake-up method of bytefilght optical transceivers for waking up a byteflight network 
on the one hand the generation of wake-up puises and on the other hand recognition of activity on the Receiver input 
(Logic "L" on RX Pin connected to transceiver) and generation of a wake-up Interrupt for the host must be supported. 

15 Stand-by mode and wake-up of the optical transceiver moduies 

[0736] The transceiver modules have the operating states "active" and "stand-by". In the active state, SOC symbols 
at least are transmitted via the bus. In the "stand-by" state, only the receiver Is active In the transceiver modules; the 
rest of the circuit Is switched off to save power. 
20 [0737] When the transceiver module Is switched on, i.e. when the operating voltage is present, the transceiver mod- 
uies are initially in the "active" state. 

[0738] The transition from the active state to the stand-by mode takes place if no bus activities are detected via the 

opticai or electrical input for a length of cdOptSleep which is defined as t_sleep in the transceiver specification, in a 
pure dynamic system this Is initiated by the SOC master switching off the SOC symbols. 

25 [0739] Transition from the "stand-by" state to the "active" state of the transceiver moduies takes place when a High- 
Low transition is detected at the electrical data input (connected to TX of a communication controller) input or when 
the following wake-up pulse is received via the optical fiber cable. The necessary duration of cdOptWake-up refers to 
one optical connection, e.g. from a node to the star coupler and Its value is given In the transceiver specification. 
[0740] Figure 73 shows an optical wake-up pulse. 

30 [0741] The wake-up pulses are generated by the bus controllers. For this purpose, one \iC starts the generation of 
these pulses and, after a specified time, switches them off again, the duration of the pulses thus being under the control 
of the nC. 

[0742] Once the wake-up pulse has been switched off or the operating voltage for the transceiver modules has been 
switched on, the bus master must start transmission of the sync pulses within cdOptSleep to prevent the transceivers 

35 from switching back into "sland-by" mode. 

[0743] in order to support this wake-up method a node Is abie to generate wake-up pulses. For this purpose, a host 
may start the generation of these puises and, after a specif led time, switches them off again, the duration of the puises 
thus being under the control of the host. Wake-up pulses are continuing, alternating pulses with 6,4 jj,s logic 'High' and 
6,4 [IS logic ,Low' levels as shown In the figure above. 

40 [0744] Once the wake-up pulse has been switched off or the operating voltage for the transceiver modules has been 
switched on, the SOC master or cold-start node must start bus activity within to prevent the transceivers from switching 
back into "stand-by" mode. 

[0745] The generation of wake-up pulses must be protected against unintended Initiation by the host. 
[0746] The Generation of wake-up pulses may be Initiated for each channel separately and only for at most one of 
45 the two channels at the same time In order to prevent the occupation of both channels by wake-up pulses In an error 

case. 

Eiectrical wake-up scheme 

50 [0747] Figure. 74 shows an electrical wake-up pulse. 

[0748] The wake-up scheme for electrical physical layer have to be defined. Requirements forthe wake-up sequence 
are: 

• there must be a clear difference between the wake-up sequence and every normal message/SOC. 

55 

• the wake-up sequence should be unequal as possible from signals generated by disturbance, e.g. EMC. 

• the wake-up sequence must be robust against disturbance e.g. EMC 
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• the bus driver shall not be woken by normal bus activity 
Proposal for the wake-up sequence: 

5 [0749] Proposal #1 (see Figure 74); 

• busy 

• idle during TBD (e.g. IFG) 

10 

• busy permanent "0" or pemanent "1" without any glitch 

• idle during TBD (e.g. IPG) 
15 t busy 

• wal<e-up during the last "busy"-detection 
Proposal #2: 

20 

[0750] 

• idle during TBD (e.g. IFG) 
25 • busy permanent "1" 

• idle during TBD (e.g. IFG) 

• busy permanent "0" 

30 

Service Proposal supported by the SW 
GotoMode 

35 Service name: GotoMode 
[0751] Parameter (In): 

• Netid Addressed communication network 

40 

• NewlVlode operating mode to be set. 
[0752] Parameter (Out): none 

[0753] Description: The NM-service GotoMode serves to set the operating mode specified by <NewMode>. 
45 [0754] Particularities: none 
[0755] Status: 
[0756] Standard: 

Startup 

50 

[0757] Service name: Startup 
[0758] Parameter (In): 

• type: active or passive 

55 

[0759] Parameter (Out): 

[0760] Description: This CC-driver-service starts up the protocol - it makes the CO to start-up the protocol. 
[0761] Particularities: The service must support 2 behaviors: 
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• active: initializing thie giobai start-up by sending messages 

• passive: participate in the giobai start-up, time-out monitored 
5 • This service is used by the NiVI, hidden from the application. 

[0762] Status: none 

Service Proposal supported by the CC 

10 

StopCom 

[0763] Service name: StopCom 
[0764] Parameter (In): 
15 [0765] Parameter (Out): 

• communication stopped 

[0766] Description: The CC stops to send messages after finishing the current communication cycle. 

20 

• The service must work with several behaviors: 

• to support the fault-free communication (finish the current communication cycle, do not start the next cycle) 

25 » to support a faulty communication (stop the communication when there is no traffic on the bus (timeout pa- 

rameter)) 

• to support the recognition of a re-start command (CancelStopCom) 

30 CancelStopCom 

[0767] Service name: CancelStopCom 
[0768] Parameter (In): 
[0769] Parameter (Out): 

35 [0770] Description: The CC does not stop to send messages after finishing the current communication cycle. 
RequestSieep 

[0771] Following service Is only required for NM support of the protocol: 

40 

Service name: RequestSieep 

Parameter (In): 
45 Parameter (Out): 

Description: The CC set the request for sleep bit in the frame header 
CancelRequestSleep 

50 

[0772] Following service Is only required for NM support of the protocol: 
Service name: CancelRequestSleep 

55 Parameter (In): 

Parameter (Out): 
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Description: Tlie CC reset the request for sieep bit(s) in tine frame iieader 
Bus-Shut-Down 
5 Objectives 

[0773] According the state of the art, a shutdown of the communication system has to be synchronized among the 
networl<ed nodes and controiied by the appiication. 
[0774] Assumptions; 

10 

• an adapted NM synchronises the bus-shutdown timing among the nodes 

• an dedicated FlexRay service does finish the communication 
15 [0775] TBD: 

• Support of the UM by a special protocoi service 
Concept 

20 

[0776] The shutdown ofthe whoie communication system orofaseiected subgroups of nodes has to be synchronized 
among the networl<ed nodes. The NiVI executed by the host, synchronize and controi the protocoi shutdown, if a shut- 
down command is signaied to the CC, the CC stops to send messages after finishing the current communication cycie. 

25 TBD: NM support by the protocol 

[0777] Protocol service for the NM to synchronize the shutdown ofthe communication system or subgroups of nodes. 
As a benefit of this service the number of receive buffers and the code size of the NiVI can be reduced. 
[0778] Assumptions: 



30 



• Use of one reserved bit in the header as sieep indication fiag, which signai a sieep request by the sending node. 

• Possibility to define a configurable sleep group in the CHI of the CC, e.g. selected frame IDs. 

• Sleep acknowledge Interrupt, which Is set If all nodes in a sleep group set there sleep Indication flag. 
Principle of operation: 

[0779] A node could signal by setting the sleep indication flag a request to shutdown the communication system or 
the sleep group, which it belongs to. Every node has configured in the CHI his sleep group by defining a set of frame 
IDs. If in all configured frame IDs the sleep indication flag is set, the CC rise his sleep acl<nowledge interrupt to the 
host. The shutdown of the CCs must now initiated synchronous by each host. 

Service Proposals supported by the SW 

GotoMode 

[0780] Service name: GotoMode 
[0781] Parameter (In): 

• Netid Addressed communication network 

• NewlVlode operating mode to be set. 
[0782] Parameter (Out): none 

[0783] Description: The NM-servlce GotoMode serves to set the operating mode specified by <NewMode>. 
[0784] Particularities: none 
[0785] Status: 
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30 



[0786] Standard: 
StopCom 

[0787] Service name: StopCom 
[0788] Parameter (In): none 
[0789] Parameter (Out): none 

[0790] Description: This CC-driver-service stops the communication via the bus by a aigorithm confinned by the 

protocoi - it maizes the CC to stop the communication after finishing the cun-ent communication cycie. 

[0791] Particularities: This CC-driver-service has to support the recognition of a re-start command e. g. from the bus 

• This service is used by the NiVI, hidden from the application. 
[0792] Status: none 

CancelStopCom 

[0793] Service name: CancelStopCom 

[0794] Parameter (In): none 

[0795] Parameter (Out): 

[0796] Description: This CC-driver-service cancels a current service StopCom 

[0797] Particularities: This service is used by the NM, hidden from the application. 

[0798] Status: 

Advantages StopCom 

[0799] 

• simple behavior inside the protocol in a perfect net 

• a master-driven behavior can be realized a distributed multi-slave behavior can be realized as well 

• BD/BG power modes are handled separately 

• the behavior of a NIVI can be adapted to the application requirements easily 
Disadvantages StopCom 

[0800] 

• the BusSleep agreement has to be done by other layers 
• e.g. by the NM service GotolVlode 

• the limp-home behavior inside a faulty net has to be specified 
Service Proposals supported by the CC 

StopCom 

[0801] Service name: StopCom 
[0802] Parameter (In): 
[0803] Parameter (Out): 

• communication stopped 

[0804] Description: The CC stops to send messages after finishing the current communication cycie. 
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• The service must work with severai behaviors: 

• to support the fauit-free communication (finish the current communication cycle, do not start the next cycie) 

5 'to support a fauity communication (stop the communication when there is no trafic on the bus (timeout param- 

eter)) 

• to support the recognition of a re-start command (CancelStopCom) 

10 CancelStopCom 

[0805] Service name: CancelStopCom 
[0806] Parameter (In): 
[0807] Parameter (Out): 

15 [0808] Description: The CC does not stop to send messages after finishing the current communication cycle, 
States and Operating Modes 
HW States and Operating Modes of the CC 

20 

Overview 

[0809] Power off: The communication controller is not supplied, the communication controller must be passive 
[081 0] Power down; The controller is supplied, the voltage is too low, the communication controller must be passive 
25 [0811] Power On: The controller is supplied correctly 

• init (bytefiight: SoftReset) 

• supply voltage is detected to support operating 

• initialization data are cleared 

• immediate halt CC clock (except host interface registers) and therefore stop communication abruptly 
Normal 

• Communication Is possible 
NormalRequest; 

• The communication controller has to be prepared to reach the state Normal 
Shutdown Request (bytefiight: Sleep) 

• stop all CC clocks except host interface registers; 

• orderly communication shut down by request/acknowledgement protocol 

• configuration data Is not available 

• the state can be left by host command 
- StandBy (bytefiight: PowerSave) 

• on demand of the host 

• In a failure condition 
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• all CC clocks off, no power consumption except leakage 

• configuration data is not available 

5 • the state can be left by any recognised wake-up event or on request of the host 

Example of a CC State Diagram 

[0812] Figure 75 shows an example of a communication controller state transition diagram. 

10 

HW States and Operating Modes of the BD 

Overview 

1S [0813] Operating modes of the bus driver: 

[0814] Power off: The BD is not supplied, the BD must be passive (no reverse current). 

[0815] Power down: The BD Is supplied, the voltage is too low, the BD must be passive (no reverse current). 

[0816] PowerOn: The BD Is supplied. 

20 • Awake 

• Init: 

• low supply voltage is detected 

25 

• Normal 

• NOT(Sleep) signaled (e.g., voltage regulator(s) active) 
30 * communication possible 

• StandBy 

• Not(Sleep) signaled (e.g., voltage regulator active) 

35 

• communication not supported 

• the state can be left on demand of the host 
40 * Sleep 

• on demand of the host 

• In a failure condition 

45 

• Sleep is to be signaled (e.g. voltage regulator passive) 

• communication not supported 
50 • wake-up monitoring active 

• the state can be left by any recognized wake-up event 

• EmergencyLimpHome 

55 

• on demand of the host 

• Sleep Is to be signaled (e.g. voltage regulator passive) 
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• bus high impedance 

• the state can be ieft just by deactivation and reactivation of the power suppiy 
5 Example of a BD State Diagram 

[0817] Figure 76 shows part 1 of an example of a bus driver state transition diagram. The bus guardian states are 

disregarded (see separate chapter) 

[081 8] Figure 77 allows part 2 of an exampie of a bus driver state transition diagram. 

10 

Overview 

[081 9] Power off: The BG is not supplied, the BG must be passive 
[0820] Power down: The BG is supplied, the voltage is too low, the BG must be passive 
15 [0821] Power On: 

• Init 

• low suppiy voltage is detected 

20 

• initialisation data are cleared 

• immediate halt BG clocic (except host interface registers) and therefore stop communication abruptly 
25 • Normal 

• Communication is possible 

• NormaiRequest 

30 

• The BG has to be prepared to reach the state Nonnal 

• Shutdown Request 

35 • stop ail BG ciocks except host interface registers; 

• orderly communication shut down by request/acknowledgement protocol 

• configuration data Is not available 

40 

• the state can be ieft by host command 

• StandBy 

45 • on demand of the host 

• in a failure condition 

• ail BG clocks off, no power consumption except leakage 

50 

• configuration data Is not available 

• the state can be left by any recognized wake-up event or on request of the host 
55 Comment: 

[0822] Tine StopCom command of the host has first to be send to the BG and second to the CC. If after the StopCom 
command the ARiVI signal is not longer send by the CC, the BG is set to the Shutdown Request state. 



166 



5/19/2010, EAST Version: 2.4.1.1 



EP 1 355 456 A1 

[0823] The CancleStopCom command of the host has first to be send to the BG and second to the CC. After the 
CancleStopCom command is received the BG enter Normal state. The sending of the ARM signal by the GO restarts 
the BG functions. 

5 Example of a BG State Diagram 

[0824] Figure 78 shows an example of a BG state transition diagram. 

Shutdown and Wake-Up handled by the OSEK-NM 

10 

Concept 

OSEK-NM inside FiexRay 
15 [0825] Requirements 

• A FlexRay system needs functionality comparable to the OSEK-NM ones 

• network-wide synchronized shutdown 

20 • network-wide consistency check (confirmed shutdown) 

Assumption 
[0826] 

25 

• integration of an adapted OSEK-NM into FlexRay 

• some NM API services are implemented in FlexRay 
30 Implementation of OSEK-NM 

[0827] 

• Software of direct OSEK NM 

35 

• S-Class model 98 body control network 

• 1 .5 - 1 .7 kByte ROM 
40 . 4-8 Byte RAM 

• 1 % bus load (1 0 messages at 1 ms per second - stable state of the ring) 
Advantages 

45 

[0828] 

• the behavior is validated 
50 Disadvantages 

[0829] 

• FlexRay has to send and receive messages to build a node-oriented monitoring algorithm 

55 

• protocol adaptations 

• bus-load 
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• the asynchronous OSEK-NM approach does not fit to the FlexRay approach perfectly 

Proposal to support Shut-Down and Startup 

5 [0830] The next figure 79 visualizes tine 1st step to adapt the OSEK-NiVI to be used inside FlexRay. in particuiar, 
Figure 79 shows a proposai (ist adaptation step) to Implement a shutdown-service and a start-up service (to be called 
by the application "NM") embedded Into the FlexRay protocol the fault-free and the faulty operation has to be taken 
Into conslderatlonfaulty e. g. stop if there is no traffic since TBDfauit-free e. g. finish the current cycle and stop 

10 Service to FiexRay 

[0831] 

• to start-up the communication actively 

15 

• to Start-up the communication passively (confirmed wal<e-up) 

• time-out monitored 
20 Service at FiexRay 

[0832] 

• to Stop the communication when finishing the current cycle 

25 

• to stop the communication when there is no traffic on the bus 

• to wait for a re-start command from the bus 

30 * to wait for a re-start command from any FlexRay service 

[0833] FiexRay does not checl< the consistency of the shut-down service Inside the whole network 

• task of a higher layer outside FlexRay (e. g. by a suitable NM) 

35 

Hints 
[0834] 

40 * Behavior to switch the BD modes Is not Included 
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Appendix K 
Error Handling and Diagnosis 

Diagnosis Interface to Physical Layer (byteflight) 

Optical Physical Layer Diagnosis 
Overview 

To supervise the quality of the optical connection between two 
devices to be assessed, the interval between the level of the 
dark current and the dark current plus the photoelectric 
current is monitored in the transceiver module. If the 
interval falls below a certain value (i.e. interval between 
dark current and dark current plus photoelectric current 
incorrect) an error bit in the transceiver module is set to 
'0' . If the interval between dark current and dark current 
plus photoelectric current is sufficient (optical transmission 
quality correct), this error bit is reset to '1'. 

The optical diagnosis function is only supported by the 
communication controller if NRZ 8N1 is chosen as coding method 
and if 10 Mbit/s is chosen as gross bitrate 

Behavior of the Optical Transceiver 

In order to signal the optical diagnosis information the 
transceiver modules behave as follows: 

While the transceiver module is transmitting a SOC symbol or 
an FSS (frame start sequence) via the LCD driver (SOC or FSS 

is transmitted via Tx Pin of the communication controller) , it 
outputs the state of this error bit at its data out pin which 
is connected to Rx of the communication controller. The 
transceiver detects the beginning of the SOC symbol or FSS 
(frame start sequence) by determining the bus idle state for 
more than 11 *gdBit and a subsequent 'L' bit to its data input 
which is connected to Tx of the communication controller. Then 
the error bit is connected to the data output of the 
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transceiver for 100 ns . The 100 ns 'L' palse at the data 
output starts between 10 ns and 220 ns after the start of the 
SOC symbol or the frame start sequence at the communication 
controller's Tx Pin. Detailed timing information may be found 
in Figure 80 below. 

Behavior of the Communication Controller 

Monitoring of the optical connections as described serves as 
an early warning system for any deterioration in the quality 
of optical transmission. 

The communication controller monitors the optical diagnosis 
information of the connected transceiver module at the nodes. 
The communication controller sets a bit in the host interface 
as soon as the transceiver signals that optical diagnosis is 
active. The bit may be cleared by the host. 

The optical diagnosis information corresponds to the error 
level "warning". 



30 Chapter M 
Bus Guardian 

Integrated Central Bus Guardian Concepts in FiexRay (not V5) 

35 

System Concepts 

[0835] The central bus guardian protects one communication channel against illegal medium access by the connect- 
ed communication controllers. If a local sub-bus is connected to a branch of a star, the communication controllers could 

40 be protected separately by decentral bus guardians. Otherwise a single failure in one communication controller can 
be led to the failure of the complete branch. The bus guardian and the host in the star are working tightly coupled so 
that a failure of either the host or the central bus guardian can affect the entire communication channel, but not both 
channels. In the case of a failure the bus guardian can be configured to close the entire communication or to open the 
communication for all slots depending on the overall application requirements. Figure 81 shows an example of a system 

45 with two cascaded stars and sub-bus on channel #2. 

Basic Concepts 

[0836] Two basic concepts are considered: 

50 

• Concept A: bus driver with Integrated bus guardian 

• Concept B: dedicated bus guardian chip. 
55 [0837] Comment: 

• One advantage of concept A is that nodes on a sub-bus of a branch require the same integrated bus driver with 
bus guardian. 
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[0838] Figure 82 shows two different concepts: Concept A comprising a bus driver chip with an integrated bus guard- 
ian, and concept B comprising a dedicated bus guardian chip. 

Concept A 

5 

Block Diagram 

[0839] Figure 83 shows a detailed graphic of concept A of nodes containing ECU and integrated bus drivers with 
integrated bus guardian. 

10 

Bus Guardian Addressing 

[0840] Figure 84 shows a detailed graphic of concept B of nodes containing an ECU and integrated bus drivers with 
an integrated bus guardian. 

15 

Concept B 
Block Diagram 

20 [0841] Figure 85 shows the basic architecture of Concept B. 



Table 33: 



Signals used in concept B 


Symbol 


Pin 


Dir 


Description 


INT 


X 


0 


Interrupt PUSH-PULL output (active LOW) 


ARM 


X 


1 


Arm signal (active LOW) from CC 


TXEN_1 


X 


1 


Enable Reception of Bus Driver #1 (active LOW) 


FIX_1 


X 


0 


Signals that Bus Driver #1 receives data (active LOW) 


SigDir_1 


X 


0 


Signals whether Bus Driver #1 is in direction from outside to inside (active LOW) 










TXEN_n 


X 


1 


Enable Reception of Bus Driver #n (active LOW) 


FlX_n 


X 


0 


Signals that Bus Driver #n receives data 








(active LOW) 


SigDir_n 


X 


0 


Signals whether Bus Driver #n Is In direction from outside to inside (active LOW) 


OSC 


X 


1 


Bus Guardian clocl< input 


RST 


X 


1 


Bus guardian reset (active LOW) from HOST 


SS 


X 


1 


SPI select input (active LOW) 


MISO 


X 


0 


SPI data output 


MOSI 


X 


1 


SPI date input 


SCK 


X 


1 


SPI clock input 


SLSC 


X 


0 


Sleep signal to switch off inhibit at star coupler 



Functional Description 

System Controller 

[0842] Figure 86 shows a state diagram of the operation modes. 



171 



5/19/2010, EAST Version: 2.4.1.1 



EP 1 355 456 A1 



Table 34: 



Signals used in concept B 


Transition 


Condition 


1 


RST input iow, Powsr on 


2 


Configuration finished AND ARM signal 


3 


SPI command, entering fail silent mode Initialisation not correct finished 


4 


Illegal star coupler access detected (e.g. illegal sending slot, access to the star coupler to long) 


5 


Counter expired, tbd 


6 


CC: Stop sending ARIVI signal 


7 


Host; Sleep Host; Wake-up Local Wake-up Low Voltage longer than e.g. 1 00ms 


8 


Bus activity detected 


9 


Host: CancleStopCom 



20 init iVIode 

[0843] In the init mode the bus guardian enables the star coupler access for all bus drivers. A monitoring due to the 
time access schema is not performed, but the access time to the star coupler could be monitored within concept B. 

25 Normai iUlode 

[0844] In the normal mode the bus guarding function is enabled. 

Warning iVIode 

30 

[0845] In the warning mode a illegal bus access has been detected and the responsible bus driver is switched off. 
Faii-Siient iVIode 

35 [0846] The fail-silent mode of the central bus guardian shall be configured to disable the star coupler access or to 

enable for all bus drivers due to safety or availability requirements of the application. Entering the fail-silent mode is 
only possible via a SPI access. The fail-silent mode can only be left by a reset or power off/on. 

Standby IVIode 

[0847] In the standby mode the bus guardian (tbd) disables the star coupler access for all bus drivers. The standby 
mode is intended to switch off the voltage regulator (via falling edge of SLPN output). In the time the bus guardian is 
still powered any bus detection results in a fall back to the init mode. Further more the Inhibit in the bus drivers will be 
switched on again (via setting SLPN output). The configuration data is only lost in case of power loss. Changing the 
operation mode via a SPI access Is not possible. 

ShutdownRequest Mode 

[0848] In the standby mode the bus guardian enables the star coupler access for all bus drivers. On detection of bus 
50 activity the bus guardian falls back to init mode. The configuration data is not lost in standby mode. It Is also possible 
to leave the standby mode via a SPI access. 

Startup 

55 [0849] The central BG must enable the communication for all nodes during startup. The bus guardian can be armed 
when the clock sync has stabilized. This can be handled over the clock sync interface. Amning by the SPI should also 
be supported. 
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Faulty Node during startup - concept B 

[0850] By limiting the access time of each #1 input line within concept B a fault that hold a driver busy for longer. To 
guarantee that no single fault block the startup, the access time of each bus driver is monitored in the initial phase, if 
a node exceed the maximal allow access time, the bus driver is deactivated. 

Self-test 

[0851] tbd, open topic 
Diagnosis 

[0852] Diagnosis Data can be transmitted by SPi from the bus guardians to the host. Within concept A the bus 
guardians must be selected. Either polling or interrupt lines can be used. The hosting ECU with communications con- 
troller can transmit the diagnosis data via configured diagnosis frames. 

Configuration 

[0853] Configuration data are transmitted via the connected SPI interface from the hosting ECU to the bus guardian 
(concept B) respectively to the selected bus guardian (concept A). 



Ciaims 

1 . A network-system with at least one node, whereby the at least one node Is coupled to a communication ilne and 
with means for communication which are able to create a communication cycle on said communication line cliar- 
acterized in that said communication cycle consists at least of a static segment and/or a dynamic segment. 

2. A device, especially a node In a network-system, with means for communication, which are able to create a com- 
munication cycle, characterized in that said communication cycle consists at least of a static segment and/or a 
dynamic segment. 

3. A method for creating a communication cycle, characterized in that said communication cycle consists at least 
of a static segment and/or a dynamic segment. 

4. A computer program comprising code means adapted to perfonn the method according to claim 3, when imple- 
mented on a computer. 

5. A computer system product, especially a memory, having a computer program according to claim 4 embodied 
therein. 
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Fig. 79 
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Fig. 83 




Fig. 84 
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Fig. 86 
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